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
