Re: Transaction issue in ShoppingList.createListReorders

[David E. Jones]

Al,







-David


On Jan 15, 2007, at 12:23 AM, Al Byers wrote:

Based on a quick review of the code I think you're right that this is a problem. It does seem to be doing a bunch of stuff in a main transaction, and then pausing that transaction and doing operations that depend on data written in the main transaction. This is unsafe and we should never write code that does this, so yeah that should be fixed. It is possible that someone tested it and it worked, and then in a different deployment it didn't. The thing that would make or break this is the transaction isolation level. If it is READ_UNCOMMITTED this code would work, but for READ_COMMITTED, REPEATABLE_READ, or SERIALIZABLE it would fail.

In ShoppingList.createListReorders (about line 166) a call is made to create

an order and then that order id is passed to
CheckOutHelper.processPaymentwhere it calls the authOrderPayments with
the following code:
               paymentResult = dispatcher.runSync("authOrderPayments",
                       UtilMisc.toMap("orderId", orderId, "userLogin",
userLogin), 180, true);


created in "CheckOutHelper.createOrder()" and the transaction is not

data in other transactions, right?



Thanks,
-Al

I test to see that the OrderHeader can be found in the code right before the service call, but once it is in the service it cannot find the OrderHeader with the same id. I change the "true" setting to "false" to not force a new transaction and the OrderHeader is found. So it would seem that the order is committed and once a new transaction is created, it cannot see uncommitted I am not comfortable enough with transactions to know if that is a bug or if there is a reason why a new transaction should be forced at the point. I hesitate to put it into JIRA until I know. Can anyone tell me about this?

smime.p7s
Description: S/MIME cryptographic signature