Parallel execution of a bpel process

Question

Hello,
I have a DbAdapter that is mapping a table and exposes operations to insert, update and select data.
This DbAdapter is being referenced in two bpel processes - bpelProcess1 and bpelProcess2:
1- bpelProcess1 -> this process firstly performs a select operation on the DbAdapter, querying for a certain row. If it returns a record, then an Id of the record is saved for further usage. If it returns nothing, then the DbAdapter is invoked again to perform an insert, and the Id of the newly created record is saved as well.
Then, this bpelProcess1 also invokes the second bpel process (bpelProcess2, the same that references the DbAdapter) and provides the Id retrieved before by the select/insert operation;
2- bpelProcess2 -> this process, after a few conditions, performs the update operation of the DbAdapter, using the Id provided by the bpelProcess1.
Now, what is the best approach to avoid incoherent data in the database?
If the process bpelProcess1 is invoked twice in a row, both instances of the process perform the select, searching for the same row - and none of them will get any data. Therefore both follow to the insert process. Only one of them should insert, the second one should already find it in the database.
The database is SqlServer, so if I change the DbAdapter from mapping a table to call a ...:
- function --> SqlServer doesn't allow to perform DML inside functions;
- procedure --> how can I return the values I need from insert/select?
What are your thoughts?
Best regards,
Bagagem

Answer 1

Bagagem wrote:
Now, what is the best approach to avoid incoherent data in the database?
If the process bpelProcess1 is invoked twice in a row, both instances of the process perform the select, searching for the same row - and none of them will get any data. Therefore both follow to the insert process. Only one of them should insert, the second one should already find it in the database.That's a classical concurrency control problem... It will arise in any language, not only in BPEL... You can solve it by using optimistic or pessimistic currency control... See link bellow for reference...
http://publib.boulder.ibm.com/infocenter/soliddb/v6r3/index.jsp?topic=/com.ibm.swg.im.soliddb.sql.doc/doc/pessimistic.vs.optimistic.concurrency.control.html
I believe an optimistic approach for your case will be to create a unique index and let both instances insert the row... One of the instances will not be able to commit at the end of the transaction (because of the unique index)... So the last instance will fail, but will execute just fine after retry (it will find the row)... A pessimistic approach will be more complex to achieve as you can not lock something that is not there yet, you may then need some extra control table to implement a pessimistic approach...
Hope this helps...
Cheers,
Vlad