Odoo Help

Welcome!

This community is for beginners and experts willing to share their Odoo knowledge. It's not a forum to discuss ideas, but a knowledge base of questions and their answers.

1

how to avoid "select for update" when creating new records in an action?

By
Alexandre Fayolle - Camptocamp
on 6/24/14, 10:39 AM 1,099 views

I have  a Model called distribution.plan. When the state attribute is "draft", I can add to a distribution.plan record a number of distribution.entitlement records to the plan. Then the user interface has a "confirm" button, when when that button is clicked, a method of the distribution plan model is called to create stock.moves for each entitlement.

My problem is that if 2 users click (or maybe with some browsers if 1 users double clicks)  on the confirm button almost simultaneously, I will get 2 stock move generated for each entitement in the end, which is incorrect.

I can work around this with a SELECT [...] FOR UPDATE NOWAIT statement in the code of the method, but this feels wrong (and it is not an idiom I've encountered in the official addons, it's only used once in stock, and this is not the same use case). So what is the correct (framework-wise) way of dealing with this?

2

Olivier Dony (odo)

--Olivier Dony (odo)--
2112
| 7 6 7
--Olivier Dony (odo)--

 

Olivier Dony (odo)
On 6/24/14, 10:50 AM

If the generation of the stock moves only occurs when the confirmation happens, then the change of `state` of the `distribution.plan` is your safeguard to prevent the transaction happening twice.

Provided that your confirm() method verifies the state is not already confirmed, then the database will prevent two transactions from writing state = 'confirmed' after reading state = 'draft' in parallel. Technically one of the transactions will be rolled back, replayed, and will notice that the plan is already confirmed.

Of course this is based on a number of assumptions regarding the lifecycle of your distribution plan, so your mileage may vary ;-)

OK, I was writing the state at the end of the method, once everything was really done. In case some action does not change the state of my main object (e.g. partial processing of the stock moves), then I'll have no other choice but lock, correct?

Camptocamp France SAS, Alexandre Fayolle - Camptocamp
on 6/24/14, 11:17 AM

Actually, writing the state at the end of the method should work too, as long as it is done in a single transaction. The key part is the "read state" + "write state" sequence of operations that the database should detect as a serialization conflict ("one transaction looked at the state, then updated it, while another one was doing the same thing...obviously one of them should have seen what the other had done first.") As for partial processing, you should perhaps consider having a state on each "entitlement" and use the same mechanism. If you partially process data without maintaining any intermediary state and write the result on unrelated records (new stock moves) then indeed the system would have a hard time detecting anything as a "duplicate" operation, and you would need custom protections such as explicit locking.

Olivier Dony (odo)
on 6/24/14, 12:03 PM

You are totally right. After further analysis, it turned out that the server-side code had no check for the current state and would only write the new state, relying on the client-side visibility of the button to prevent the actions from being triggered in the wrong state, which is obviously a very bad idea.

Camptocamp France SAS, Alexandre Fayolle - Camptocamp
on 6/25/14, 2:17 AM

Your Answer

Please try to give a substantial answer. If you wanted to comment on the question or answer, just use the commenting tool. Please remember that you can always revise your answers - no need to answer the same question twice. Also, please don't forget to vote - it really helps to select the best questions and answers!

About This Community

This community is for professionals and enthusiasts of our products and services. Read Guidelines

Question tools

1 follower(s)

Stats

Asked: 6/24/14, 10:39 AM
Seen: 1099 times
Last updated: 3/16/15, 8:10 AM