c2c-oerpscenario team mailing list archive

["Olivier Dony \(OpenERP\)" <770243@xxxxxxxxxxxxxxxxxx>]

@Sinoj: the traceback you encountered does not come from the stock
reservation itself, but is due to the attribution of a sequence number
for the new picking list (during SO confirmation), and is a different topic.

*Short answer*: it is not technically a bug, and cannot be solved
_properly_ without deep changes. The second user can simply try again
after a few seconds. We are planning improvements in this area in 6.1.

*Long answer*: There are only 2 situations in OpenERP where this
temporary failure may occur:
1) when requesting the next number in a sequence, if another user
request is still being processed, and had requested the previous number
of this same sequence
2) when requesting the reservation of a certain product in a certain
location, if another user request is still being processed and reserved
the same product in the same location
Technically, having this "fail-fast" behavior while trying to acquire
locks on these critical resources is required to be able to guarantee
the transactionality of stock reservation and sequence attribution,
while still making sure deadlocks can never happen.

Granted, the user feedback could be improved...

In 6.1 we will have a new type of sequence that can be used for cases
where "gapless" is not a requirement (e.g. for picking list sequence
numbers), and will not have the resource contention issue.

BTW, for those who are writing RPC automation code, such special cases
must be handled properly, you cannot simply fire-and-forget. You can of
course use heuristics to retry the transaction if you know the typical
usage pattern very well.

I think further discussion on this is off-topic wrt current bug (perhaps
belongs to its own thread on the framework mailing-list)

-- 
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.
https://bugs.launchpad.net/bugs/770243

Title:
  Creating 4000+ locations slow down the mrp module installations and
  confirming sale order.

Status in OpenERP Modules (addons):
  Fix Committed

Bug description:
  Hi,
  We imported 4197 locations in openerp. After that installation of mrp modules taking hours and conforming one sale order taking more than one minute. The system is slowing down on the function _product_reserve which is in "bin/addons/stock/stock.py" in class stock_location line 362.

  Sometimes it is throwing the following error
  OperationalError: out of shared memory
  HINT: You might need to increase max_locks_per_transaction.

  The server we are using 6.0.2 stable.
  The locations we used to import is attached with this bug report.

  Please improve the performance of _product_reserve function so that it
  will not hang when the number of locations are in thousands range.

  Thank you.