问题:
多线程进行进行数据库操作,主要调用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
==========================================
番外篇:
如果您觉得以上内容对您有帮助,请进入以下地址支持步科大神: [检测到链接无效,已移除] br />
谢谢!
==========================================
Tommy
-
OpenERP concurrent transaction -
Openerp-审批流的实现技术[quote author=Jeff link=topic=16203.msg27358#msg27358 date=1389931818]
审批人的确定是个很复杂的业务逻辑,很难做到通用。其他软件在可配置方面做得不错,OE这里还差一些。
要考虑组织架构和职能来确认审批人,要考虑审批人多久未响应需要提醒,要考虑审批人不在岗要代理人审批,要考虑审批人在岗时代理人不能批。
[/quote]
基本谈到了所有的需求点。 -
Openerp-审批流的实现技术[quote author=mrshelly link=topic=16203.msg27354#msg27354 date=1389926353]
不要在 workflow 这样大框架下玩.会比较好.
比如 ,你关注费用的审批. 那么, 你就做 wizard 来玩这些事就OK了...
[/quote]
要做通用的。集成oa功能。需求是这样。 -
Openerp-审批流的实现技术如何实现在提交的时候选人。
只有选定的人才有权限对表单进行提交或者退回操作。
我的思路是:
1)提交时用向导或者动作弹窗给选人。根据提交表单的状态通过一定方法计算出下个状态,在通过某张表A得到此表单对象下个状态对应的审批人。
2)提交后/退回后将审批结果记录到log表,同时更新表B(记录当前审批人)
3) 根据表B决定哪些人可以对某个表单进行提交或者退回操作。
4)重复以上步骤直至审批走完。
可行性:
某个对象的某个表单,只有指定的人才能够操作(访问),需要对系统的权限机制做一个调整,改动比较大。而且不知道是否可以兼容新的oe版本。
以上只是初步方案,抛砖引玉。
==================================================================
jeff 提到:给表单增加字段的方式来实现选人,不用弹窗。