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

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

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

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

OpenERP concurrent transaction



  • 问题:<br />    多线程进行进行数据库操作,主要调用cr进行直接操作的时候,抛出错误:InternalError: current transaction is aborted, commands ignored until end of transaction block.<br />    啥意思呢,就是oe并发的transaction会被放弃。<br /><br />步科大大对此问题进行了全面权威总结:<br />    首先,看代码(sql_db.py):<br />    <br />    class Cursor(object):<br />    """Represents an open transaction to the PostgreSQL DB backend,<br />      acting as a lightweight wrapper around psycopg2's<br />      psycopg1cursor objects.<br /><br />        Cursor is the object behind the cr variable used all<br />        over the OpenERP code.<br /><br />        .. rubric:: [color=red]Transaction Isolation[/color]<br /><br />        One very important property of database transactions is the<br />        level of isolation between concurrent transactions.<br />        The SQL standard defines four levels of transaction isolation,<br />        ranging from the most strict Serializable level, to the least<br />        strict Read Uncommitted level. These levels are defined in<br />        terms of the phenomena that must not occur between concurrent<br />        transactions, such as dirty read, etc.<br />        In the context of a generic business data management software<br />        such as OpenERP, [color=red]we need the best guarantees that no data<br />        corruption can ever be cause by simply running multiple<br />        transactions in parallel[/color]. Therefore, the preferred level would<br />        be the serializable level, which ensures that a set of<br />        transactions is guaranteed to produce the same effect as<br />        running them one at a time in some order.<br /><br />        However, most database management systems implement a limited<br />        serializable isolation in the form of<br />        snapshot isolation &lt;http://en.wikipedia.org/wiki/Snapshot_isolation&gt;_,<br />        providing most of the same advantages as True Serializability,<br />        with a fraction of the performance cost.<br />        With PostgreSQL up to version 9.0, this snapshot isolation was<br />        the implementation of both the REPEATABLE READ and<br />        SERIALIZABLE levels of the SQL standard.<br />        As of PostgreSQL 9.1, the previous snapshot isolation implementation<br />        was kept for REPEATABLE READ, while a new SERIALIZABLE<br />        level was introduced, providing some additional heuristics to<br />        detect a concurrent update by parallel transactions, and forcing<br />        one of them to rollback.<br /><br />        OpenERP implements its own level of locking protection<br />        for transactions that are highly likely to provoke concurrent<br />        updates, such as stock reservations or document sequences updates.<br />        Therefore we mostly care about the properties of snapshot isolation,<br />        but we don't really need additional heuristics to trigger transaction<br />        rollbacks, as we are taking care of triggering instant rollbacks<br />        ourselves when it matters (and we can save the additional performance<br />        hit of these heuristics).<br /><br />        As a result of the above, we have selected REPEATABLE READ as<br />        the default transaction isolation level for OpenERP cursors, as<br />        it will be mapped to the desired snapshot isolation level for<br />        all supported PostgreSQL version (8.3 - 9.x).<br /><br />        Note: up to psycopg2 v.2.4.2, psycopg2 itself remapped the repeatable<br />        read level to serializable before sending it to the database, so it would<br />        actually select the new serializable mode on PostgreSQL 9.1. Make<br />        sure you use psycopg2 v2.4.2 or newer if you use PostgreSQL 9.1 and<br />        the performance hit is a concern for you.<br /><br />        .. attribute:: cache<br /><br />            Cache dictionary with a "request" (-ish) lifecycle, only lives as<br />            long as the cursor itself does and proactively cleared when the<br />            cursor is closed.<br /><br />            This cache should only be used to store repeatable reads as it<br />            ignores rollbacks and savepoints, it should not be used to store<br />            any data which may be modified during the life of the cursor.<br /><br />    """<br />    <br /><br />    <br />    2. 以上是cr应用的全部说明,可能部分朋友看不太懂。没关系,看下面的就好了,(by  步科总结)<br /><br />        1. OE使用了最高的数据库隔离级别 ISOLATION_LEVEL_REPEATABLE_READ,因此事物(transaction)不能并发。<br />        2. 多线程的情况下,其实很难避免事物的并发。<br />        3. 在一次请求通常被OE处理为一个transaction块(savepoint)<br />        4. 但是autocommit可以让每条sql语句都是一个事物(transaction)。这样pg会尽快执行完。从而降低事物(transaction)并发的概率。<br /><br />      so,编程中注意:<br />        1. OE数据库操作,尽量避免多线程。<br />        2. 如果一定要用,则尽量少开些线程。不够的话,请加消息队列缓冲。<br />        3. 使用autocommit<br /><br />    ==========================================<br />          番外篇:<br />                  如果您觉得以上内容对您有帮助,请进入以下地址支持步科大神: https://me.alipay.com/wangbuke<br />                <br /><br />          谢谢!<br />    ==========================================



  • 问题:<br />    多线程进行进行数据库操作,主要调用cr进行直接操作的时候,抛出错误:InternalError: current transaction is aborted, commands ignored until end of transaction block.<br />    啥意思呢,就是oe并发的transaction会被放弃。<br /><br />步科大大对此问题进行了全面权威总结:<br />    首先,看代码(sql_db.py):<br />    <br />    class Cursor(object):<br />    """Represents an open transaction to the PostgreSQL DB backend,<br />      acting as a lightweight wrapper around psycopg2's<br />      psycopg1cursor objects.<br /><br />        Cursor is the object behind the cr variable used all<br />        over the OpenERP code.<br /><br />        .. rubric:: [color=red]Transaction Isolation[/color]<br /><br />        One very important property of database transactions is the<br />        level of isolation between concurrent transactions.<br />        The SQL standard defines four levels of transaction isolation,<br />        ranging from the most strict Serializable level, to the least<br />        strict Read Uncommitted level. These levels are defined in<br />        terms of the phenomena that must not occur between concurrent<br />        transactions, such as dirty read, etc.<br />        In the context of a generic business data management software<br />        such as OpenERP, [color=red]we need the best guarantees that no data<br />        corruption can ever be cause by simply running multiple<br />        transactions in parallel[/color]. Therefore, the preferred level would<br />        be the serializable level, which ensures that a set of<br />        transactions is guaranteed to produce the same effect as<br />        running them one at a time in some order.<br /><br />        However, most database management systems implement a limited<br />        serializable isolation in the form of<br />        snapshot isolation &lt;http://en.wikipedia.org/wiki/Snapshot_isolation&gt;_,<br />        providing most of the same advantages as True Serializability,<br />        with a fraction of the performance cost.<br />        With PostgreSQL up to version 9.0, this snapshot isolation was<br />        the implementation of both the REPEATABLE READ and<br />        SERIALIZABLE levels of the SQL standard.<br />        As of PostgreSQL 9.1, the previous snapshot isolation implementation<br />        was kept for REPEATABLE READ, while a new SERIALIZABLE<br />        level was introduced, providing some additional heuristics to<br />        detect a concurrent update by parallel transactions, and forcing<br />        one of them to rollback.<br /><br />        OpenERP implements its own level of locking protection<br />        for transactions that are highly likely to provoke concurrent<br />        updates, such as stock reservations or document sequences updates.<br />        Therefore we mostly care about the properties of snapshot isolation,<br />        but we don't really need additional heuristics to trigger transaction<br />        rollbacks, as we are taking care of triggering instant rollbacks<br />        ourselves when it matters (and we can save the additional performance<br />        hit of these heuristics).<br /><br />        As a result of the above, we have selected REPEATABLE READ as<br />        the default transaction isolation level for OpenERP cursors, as<br />        it will be mapped to the desired snapshot isolation level for<br />        all supported PostgreSQL version (8.3 - 9.x).<br /><br />        Note: up to psycopg2 v.2.4.2, psycopg2 itself remapped the repeatable<br />        read level to serializable before sending it to the database, so it would<br />        actually select the new serializable mode on PostgreSQL 9.1. Make<br />        sure you use psycopg2 v2.4.2 or newer if you use PostgreSQL 9.1 and<br />        the performance hit is a concern for you.<br /><br />        .. attribute:: cache<br /><br />            Cache dictionary with a "request" (-ish) lifecycle, only lives as<br />            long as the cursor itself does and proactively cleared when the<br />            cursor is closed.<br /><br />            This cache should only be used to store repeatable reads as it<br />            ignores rollbacks and savepoints, it should not be used to store<br />            any data which may be modified during the life of the cursor.<br /><br />    """<br />    <br /><br />    <br />    2. 以上是cr应用的全部说明,可能部分朋友看不太懂。没关系,看下面的就好了,(by  步科总结)<br /><br />        1. OE使用了最高的数据库隔离级别 ISOLATION_LEVEL_REPEATABLE_READ,因此事物(transaction)不能并发。<br />        2. 多线程的情况下,其实很难避免事物的并发。<br />        3. 在一次请求通常被OE处理为一个transaction块(savepoint)<br />        4. 但是autocommit可以让每条sql语句都是一个事物(transaction)。这样pg会尽快执行完。从而降低事物(transaction)并发的概率。<br /><br />      so,编程中注意:<br />        1. OE数据库操作,尽量避免多线程。<br />        2. 如果一定要用,则尽量少开些线程。不够的话,请加消息队列缓冲。<br />        3. 使用autocommit<br /><br />    ==========================================<br />          番外篇:<br />                  如果您觉得以上内容对您有帮助,请进入以下地址支持步科大神: https://me.alipay.com/wangbuke<br />                <br /><br />          谢谢!<br />    ==========================================



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



  • 由于业务调整,收款主页已于2014年5月4日起停止服务,感谢您一直以来的支持!点此了解详情<br /><br />您可以使用以下方式来收款:<br />1、在手机上,大家可以使用“当面付”功能,与朋友通过声波支付进行收款;下载最新的支付宝钱包<br />2、在电脑上,使用我要收款功能进行收款。



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


登录后回复
 

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