PaymentGatewayResponse Simultaneous create breaks by deadlock ?

[oceatoon]

Hi ofbizians

We have created a clone of the PaypallEvents.java for a new payment type,
where we have the same type of autherisation and prepared orderId processes
as ofbiz.

Our problem appears when an allready autherized order is about to pass to
prepared aka Captured,
in the same time a new order comes up asking for autherisation.

These two different orders both try to "create" into PaymentGatewayResponse
(2 diff states)
but unfortunetly a deadlock appears on the order in "prepared aka Capture"
state and only the autherisation comes through properly.

This happens on the Delegator.create method which rolls every thing back but
unfortunetly the payment is send to the payment company leaving a
problematic order state on our ofbiz side.
By analysing the code it seems that the GenericDAO holds on to the elements
he needs for the create, and when a simultaneous request tries to access
this same information appears a deadlock.

is it possible not to lock on some tables ?
is there a best practised or simply a right way to do this to avoid such
concurent access and locking problems ?

Best Regards

Tibor

[David E Jones-2]

Which transaction isolation level are you using?

Are you sure this is because of locking in the database? What is the  
error coming back from the database?

-David


On Nov 16, 2006, at 8:25 AM, tibor katelbach wrote:

> Hi ofbizians
>
> We have created a clone of the PaypallEvents.java for a new payment  
> type,
> where we have the same type of autherisation and prepared orderId  
> processes
> as ofbiz.
>
> Our problem appears when an allready autherized order is about to  
> pass to
> prepared aka Captured,
> in the same time a new order comes up asking for autherisation.
>
> These two different orders both try to "create" into  
> PaymentGatewayResponse
> (2 diff states)
> but unfortunetly a deadlock appears on the order in "prepared aka  
> Capture"
> state and only the autherisation comes through properly.
>
> This happens on the Delegator.create method which rolls every thing  
> back but
> unfortunetly the payment is send to the payment company leaving a
> problematic order state on our ofbiz side.
> By analysing the code it seems that the GenericDAO holds on to the  
> elements
> he needs for the create, and when a simultaneous request tries to  
> access
> this same information appears a deadlock.
>
> is it possible not to lock on some tables ?
> is there a best practised or simply a right way to do this to avoid  
> such
> concurent access and locking problems ?
>
> Best Regards
>
> Tibor