credativ team mailing list archive
-
credativ team
-
Mailing list archive
-
Message #01419
[Bug 746620] Re: Implementation of faster gap-tolerant sequences
The new gap-tolerant (postgres-backed) sequences have been added in
trunk as of revision 3686 revid:
al@xxxxxxxxxxx-20110930190053-ovd4qlwt7hll02ch.
This adds a choice of "implementation" per sequence: "Standard" (the new
gap-tolerant one) or "No gap" (the old one, with locking). The default
is now to use the faster Standard/Gap-tolerant sequence for all
sequences where gaps don't matter much, like the Sale Journal (Sale
order numbers), Purchase Journal, etc. The "No Gap" variant is meant to
be used only for the few sequences with legal requirements, such as the
one for numbering accounting journal entries.
** Changed in: openobject-server
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of OpenERP
Framework Experts, which is subscribed to OpenERP Server.
https://bugs.launchpad.net/bugs/746620
Title:
Implementation of faster gap-tolerant sequences
Status in OpenERP Server:
Fix Released
Bug description:
OpenERP is classified as an Enterprise class software package. Meaning
that more than one person, at least 2 should be able to use the system
simultaneously. Like packers shipping products, taking orders,
reserving products. I find that in fact, it is not possible for
creation of stock moves simultaneously.
Say I am importing orders from a shop. It is creating stock moves because the order is paid.
At the same time I am shipping products which is normal for an ERP system.
I might also import orders from a separate shop say a POS system.
It is not possible!
[2011-03-31 13:10:47,657][midwestsupplies] WARNING:stock.location:Failed attempt to reserve 1.0 x product 1669, li
kely due to another transaction already in progress. Next attempt is likely to work. Detailed error available at D
EBUG level.
OperationalError: could not obtain lock on row in relation "ir_sequence"
Two different errors.
I can only perform one action at a time!
What happens is that any time the program calls for a stock_move it will lock the stock_move table so no other process can access it which means that you cant do hardly anything unless its done individually. Now say with a MS system, or any Enterprise system would be able to handle many simultaneous actions but this program has a serious architecture flaw to not be able to support this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-server/+bug/746620/+subscriptions