On Thu, Jun 2, 2011 at 12:33 PM, Olivier Dony (OpenERP) < [email protected]> wrote:
> [...] > > For case 1, different strategies have different properties, as > illustrated in the comparison I am attaching to this bug. Using SELECT > FOR UPDATE with the NOWAIT flag is basically a pessimistic locking > strategy with immediate conflict detection. This looks to me like the > best strategy when you know all transactions are going to update the row > in the same way, which is the case for ir.sequence. With this strategy > you prevent transactions to even read the about-to-change value (making > sure it cannot be used erroneously to produce a report, an email, etc. > before detecting the conflict), and you also detect the conflict > immediately, instead of waiting a bit to fail later anyway. > Olivier, sorry, I still don't get it: if the sequence is locked by some batch (like the MRP), what is the benefit of "not waiting even a second before failing". Can you cite a use case where there is a benefit in not waiting even for a second? You say: " instead of waiting a bit to fail later anyway." If take the MRP batch case or other batches like we have with base_sale_multichannels, there is often a commit after a record is processed, and I believe this is a good practice as it would prevent a full roll back just because of some specific record issue. Since there are commit and since the batch spend time doing other things* before locking the ir_sequence table, unless I miss something it means that there are small time periods while the ir_sequence is not locked. Am I wrong? Then, unless I miss something, if we wait say up to 1 sec when requesting a sequence number, wouldn't have get a chance to be able to get our sequence number during those small periods it's not locked? And overall, what is the benefit of waiting 0 millisecond before blowing into a locked sequence table exception? Any use case where this really bring value? Thanks. * I even consider very seriously to introduce some sleep(a few millisecs) at least in base_sale_multi_channels import batches if that would help making other process more fluid (and so may be we could optionally do it in the MRP batch too). -- 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/746620 Title: Implementation of faster gap-tolerant sequences Status in OpenERP Server: Confirmed 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. _______________________________________________ Mailing list: https://launchpad.net/~c2c-oerpscenario Post to : [email protected] Unsubscribe : https://launchpad.net/~c2c-oerpscenario More help : https://help.launchpad.net/ListHelp
