Transaction issue in ShoppingList.createListReorders

[Al Byers <by...@automationgroups.com>]

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);

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
created in "CheckOutHelper.createOrder()" and the transaction is not
committed and once a new transaction is created, it cannot see uncommitted
data in other transactions, right?

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?

Thanks,
-Al

Re: Transaction issue in ShoppingList.createListReorders

["David E. Jones" <jo...@hotwaxmedia.com>]

Al,

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.

-David


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

> 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);
>
> 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
> created in "CheckOutHelper.createOrder()" and the transaction is not
> committed and once a new transaction is created, it cannot see  
> uncommitted
> data in other transactions, right?
>
> 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?
>
> Thanks,
> -Al