This content has been marked as final. Show 3 replies
I've managed to by using UserTransaction and by demarcating explicitly the commit/rollback.
Now my issue is: how can I be sure that, from the time by which I decrement the item quantity in the database to the commit, no other transaction is decrementing the quantity of the same item as well??? Am I protected against this???
Its sad to see someone using EJB technology and then completely throw all benefits of it out of the window. I highly advise you to look into Container Managed Transactions; learn what they help you to do and then apply it. When you know how, it will put a smile on your face as you'll see the transaction management stuff disappear before your eyes.
, from the time by which I decrement the item quantity in the database to the commit, no other transaction is decrementing the quantity of the same item as well??? Am I protected against this???Concurrency is a hard problem with no clearly defined answers to it other than "you need to design the code to guard against concurrency problems". In this specific case, the database protects against this happening by applying a row lock or a table lock while the transaction is active and you are making modifications. For more information about that, you should consult the documentation relating to your specific DBMS.
My issue with the container-managed transaction is the following:
In the checkout() method, I decrease the quantity of the items that are ordered.
But, when I find an order item for which the quantity is greater than the availability, I'd like to throw an exception and having the transaction rolled-back.
Now, if I throw a checked exception, the transaction does not roll back.
If I throw a nonchecked exception, the transaction is rolledback but the EJB is no longer available.
How can I resolve this situation?
Edited by: robyonrails on Apr 12, 2012 1:40 PM
I used EJBContext.setRollbackOnly() and it worked!