Odoo中文社区可以通过以下三个域名访问:shine-it.net , odoocn.org,odoo.net.cn

原论坛用户的基本信息和发帖这里都予以保留,请注意:原论坛用户无需重新注册新用户,但是您的密码需要重置

开发人员可以登录gitter讨论组: http://gitter.im/odoo-china/Talk, 需要github账号

如果您登录系统碰到问题,请在微信公众号留言:

OpenERP concurrent transaction



  • 问题:
        多线程进行进行数据库操作,主要调用cr进行直接操作的时候,抛出错误:InternalError: current transaction is aborted, commands ignored until end of transaction block.
        啥意思呢,就是oe并发的transaction会被放弃。

    步科大大对此问题进行了全面权威总结:
        首先,看代码(sql_db.py):
       
        class Cursor(object):
        """Represents an open transaction to the PostgreSQL DB backend,
          acting as a lightweight wrapper around psycopg2's
          psycopg1cursor objects.

            Cursor is the object behind the cr variable used all
            over the OpenERP code.

            .. rubric:: [color=red]Transaction Isolation[/color]

            One very important property of database transactions is the
            level of isolation between concurrent transactions.
            The SQL standard defines four levels of transaction isolation,
            ranging from the most strict Serializable level, to the least
            strict Read Uncommitted level. These levels are defined in
            terms of the phenomena that must not occur between concurrent
            transactions, such as dirty read, etc.
            In the context of a generic business data management software
            such as OpenERP, [color=red]we need the best guarantees that no data
            corruption can ever be cause by simply running multiple
            transactions in parallel[/color]. Therefore, the preferred level would
            be the serializable level, which ensures that a set of
            transactions is guaranteed to produce the same effect as
            running them one at a time in some order.

            However, most database management systems implement a limited
            serializable isolation in the form of
            snapshot isolation <http://en.wikipedia.org/wiki/Snapshot_isolation>_,
            providing most of the same advantages as True Serializability,
            with a fraction of the performance cost.
            With PostgreSQL up to version 9.0, this snapshot isolation was
            the implementation of both the REPEATABLE READ and
            SERIALIZABLE levels of the SQL standard.
            As of PostgreSQL 9.1, the previous snapshot isolation implementation
            was kept for REPEATABLE READ, while a new SERIALIZABLE
            level was introduced, providing some additional heuristics to
            detect a concurrent update by parallel transactions, and forcing
            one of them to rollback.

            OpenERP implements its own level of locking protection
            for transactions that are highly likely to provoke concurrent
            updates, such as stock reservations or document sequences updates.
            Therefore we mostly care about the properties of snapshot isolation,
            but we don't really need additional heuristics to trigger transaction
            rollbacks, as we are taking care of triggering instant rollbacks
            ourselves when it matters (and we can save the additional performance
            hit of these heuristics).

            As a result of the above, we have selected REPEATABLE READ as
            the default transaction isolation level for OpenERP cursors, as
            it will be mapped to the desired snapshot isolation level for
            all supported PostgreSQL version (8.3 - 9.x).

            Note: up to psycopg2 v.2.4.2, psycopg2 itself remapped the repeatable
            read level to serializable before sending it to the database, so it would
            actually select the new serializable mode on PostgreSQL 9.1. Make
            sure you use psycopg2 v2.4.2 or newer if you use PostgreSQL 9.1 and
            the performance hit is a concern for you.

            .. attribute:: cache

                Cache dictionary with a "request" (-ish) lifecycle, only lives as
                long as the cursor itself does and proactively cleared when the
                cursor is closed.

                This cache should only be used to store repeatable reads as it
                ignores rollbacks and savepoints, it should not be used to store
                any data which may be modified during the life of the cursor.

        """
       

       
        2. 以上是cr应用的全部说明,可能部分朋友看不太懂。没关系,看下面的就好了,(by  步科总结)

            1. OE使用了最高的数据库隔离级别 ISOLATION_LEVEL_REPEATABLE_READ,因此事物(transaction)不能并发。
            2. 多线程的情况下,其实很难避免事物的并发。
            3. 在一次请求通常被OE处理为一个transaction块(savepoint)
            4. 但是autocommit可以让每条sql语句都是一个事物(transaction)。这样pg会尽快执行完。从而降低事物(transaction)并发的概率。

          so,编程中注意:
            1. OE数据库操作,尽量避免多线程。
            2. 如果一定要用,则尽量少开些线程。不够的话,请加消息队列缓冲。
            3. 使用autocommit

        ==========================================
              番外篇:
                      如果您觉得以上内容对您有帮助,请进入以下地址支持步科大神: https://me.alipay.com/wangbuke
                   

              谢谢!
        ==========================================



  • 问题:
        多线程进行进行数据库操作,主要调用cr进行直接操作的时候,抛出错误:InternalError: current transaction is aborted, commands ignored until end of transaction block.
        啥意思呢,就是oe并发的transaction会被放弃。

    步科大大对此问题进行了全面权威总结:
        首先,看代码(sql_db.py):
       
        class Cursor(object):
        """Represents an open transaction to the PostgreSQL DB backend,
          acting as a lightweight wrapper around psycopg2's
          psycopg1cursor objects.

            Cursor is the object behind the cr variable used all
            over the OpenERP code.

            .. rubric:: [color=red]Transaction Isolation[/color]

            One very important property of database transactions is the
            level of isolation between concurrent transactions.
            The SQL standard defines four levels of transaction isolation,
            ranging from the most strict Serializable level, to the least
            strict Read Uncommitted level. These levels are defined in
            terms of the phenomena that must not occur between concurrent
            transactions, such as dirty read, etc.
            In the context of a generic business data management software
            such as OpenERP, [color=red]we need the best guarantees that no data
            corruption can ever be cause by simply running multiple
            transactions in parallel[/color]. Therefore, the preferred level would
            be the serializable level, which ensures that a set of
            transactions is guaranteed to produce the same effect as
            running them one at a time in some order.

            However, most database management systems implement a limited
            serializable isolation in the form of
            snapshot isolation <http://en.wikipedia.org/wiki/Snapshot_isolation>_,
            providing most of the same advantages as True Serializability,
            with a fraction of the performance cost.
            With PostgreSQL up to version 9.0, this snapshot isolation was
            the implementation of both the REPEATABLE READ and
            SERIALIZABLE levels of the SQL standard.
            As of PostgreSQL 9.1, the previous snapshot isolation implementation
            was kept for REPEATABLE READ, while a new SERIALIZABLE
            level was introduced, providing some additional heuristics to
            detect a concurrent update by parallel transactions, and forcing
            one of them to rollback.

            OpenERP implements its own level of locking protection
            for transactions that are highly likely to provoke concurrent
            updates, such as stock reservations or document sequences updates.
            Therefore we mostly care about the properties of snapshot isolation,
            but we don't really need additional heuristics to trigger transaction
            rollbacks, as we are taking care of triggering instant rollbacks
            ourselves when it matters (and we can save the additional performance
            hit of these heuristics).

            As a result of the above, we have selected REPEATABLE READ as
            the default transaction isolation level for OpenERP cursors, as
            it will be mapped to the desired snapshot isolation level for
            all supported PostgreSQL version (8.3 - 9.x).

            Note: up to psycopg2 v.2.4.2, psycopg2 itself remapped the repeatable
            read level to serializable before sending it to the database, so it would
            actually select the new serializable mode on PostgreSQL 9.1. Make
            sure you use psycopg2 v2.4.2 or newer if you use PostgreSQL 9.1 and
            the performance hit is a concern for you.

            .. attribute:: cache

                Cache dictionary with a "request" (-ish) lifecycle, only lives as
                long as the cursor itself does and proactively cleared when the
                cursor is closed.

                This cache should only be used to store repeatable reads as it
                ignores rollbacks and savepoints, it should not be used to store
                any data which may be modified during the life of the cursor.

        """
       

       
        2. 以上是cr应用的全部说明,可能部分朋友看不太懂。没关系,看下面的就好了,(by  步科总结)

            1. OE使用了最高的数据库隔离级别 ISOLATION_LEVEL_REPEATABLE_READ,因此事物(transaction)不能并发。
            2. 多线程的情况下,其实很难避免事物的并发。
            3. 在一次请求通常被OE处理为一个transaction块(savepoint)
            4. 但是autocommit可以让每条sql语句都是一个事物(transaction)。这样pg会尽快执行完。从而降低事物(transaction)并发的概率。

          so,编程中注意:
            1. OE数据库操作,尽量避免多线程。
            2. 如果一定要用,则尽量少开些线程。不够的话,请加消息队列缓冲。
            3. 使用autocommit

        ==========================================
              番外篇:
                      如果您觉得以上内容对您有帮助,请进入以下地址支持步科大神: https://me.alipay.com/wangbuke
                   

              谢谢!
        ==========================================



  • 这个对于外部程序调用OpenERP执行批量写操作有很重要的意义,谢谢分享。



  • 由于业务调整,收款主页已于2014年5月4日起停止服务,感谢您一直以来的支持!点此了解详情

    您可以使用以下方式来收款:
    1、在手机上,大家可以使用“当面付”功能,与朋友通过声波支付进行收款;下载最新的支付宝钱包
    2、在电脑上,使用我要收款功能进行收款。



  • 步科的分析非常到位; 同时感谢tommy无私分享, it helps a lot;


登录后回复
 

与 Odoo 中文社区 的连接断开,我们正在尝试重连,请耐心等待