Comment 12 for bug 770243

@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)