Interesting... perhaps this is caused by double-clicking on the submit order button?

There is some JavaScript that disables the button after it is clicked to help avoid this. Is that in place and working on your site?

-David


On Nov 1, 2006, at 4:18 AM, Sebastian Schirmer wrote:

Hi David,

the failure occures only sometimes on submitting a new order by an enduser on the confirm page. The clients gots the confirm page again but not the confirmed page. Ofbiz generates a new orderid with the same details. The original OrderId is stored in the field firstAttemptOrderId (Table OrderHeader)


the ofbiz log reports a deadlock:

2006-10-29 07:02:43,507 397804255[   GenericDelegator.java:600:ERROR]
---- exception report ---------------------------------------------------------- Failure in create operation for entity [OrderPaymentPreference]: org.ofbiz.entity.GenericEntityException: Exception while inserting the following entity: [GenericEntity:OrderPaymentPreference] [billingPostalCode,null()] [createdByUserLogin,[EMAIL PROTECTED](java.lang.String)] [createdDate,2006-10-29 07:02:41.21(java.sql.Timestamp)] [createdStamp,2006-10-29 07:02:41.405(java.sql.Timestamp)] [createdTxStamp,2006-10-29 07:02:41.217(java.sql.Timestamp)] [lastUpdatedStamp,2006-10-29 07:02:41.405(java.sql.Timestamp)] [lastUpdatedTxStamp,2006-10-29 07:02:41.217(java.sql.Timestamp)] [manualAuthCode,null()][manualRefNum,null()][maxAmount,19.95 (java.lang.Double)][orderId,VUK22870(java.lang.String)] [orderPaymentPreferenceId,22870(java.lang.String)][overflowFlag,Y (java.lang.String)][paymentMethodId,24626(java.lang.String)] [paymentMethodTypeId,CREDIT_CARD(java.lang.String)][presentFlag,N (java.lang.String)][statusId,PAYMENT_NOT_AUTH(java.lang.String)] (while inserting: [GenericEntity:OrderPaymentPreference] [billingPostalCode,null()] [createdByUserLogin,[EMAIL PROTECTED](java.lang.String)] [createdDate,2006-10-29 07:02:41.21(java.sql.Timestamp)] [createdStamp,2006-10-29 07:02:41.405(java.sql.Timestamp)] [createdTxStamp,2006-10-29 07:02:41.217(java.sql.Timestamp)] [lastUpdatedStamp,2006-10-29 07:02:41.405(java.sql.Timestamp)] [lastUpdatedTxStamp,2006-10-29 07:02:41.217(java.sql.Timestamp)] [manualAuthCode,null()][manualRefNum,null()][maxAmount,19.95 (java.lang.Double)][orderId,VUK22870(java.lang.String)] [orderPaymentPreferenceId,22870(java.lang.String)][overflowFlag,Y (java.lang.String)][paymentMethodId,24626(java.lang.String)] [paymentMethodTypeId,CREDIT_CARD(java.lang.String)][presentFlag,N (java.lang.String)][statusId,PAYMENT_NOT_AUTH(java.lang.String)] (SQL Exception while executing the following:INSERT INTO public.ORDER_PAYMENT_PREFERENCE (ORDER_PAYMENT_PREFERENCE_ID, ORDER_ID, PAYMENT_METHOD_TYPE_ID, PAYMENT_METHOD_ID, SECURITY_CODE, PRESENT_FLAG, OVERFLOW_FLAG, MAX_AMOUNT, PROCESS_ATTEMPT, BILLING_POSTAL_CODE, MANUAL_AUTH_CODE, MANUAL_REF_NUM, STATUS_ID, CREATED_DATE, CREATED_BY_USER_LOGIN, LAST_UPDATED_STAMP, LAST_UPDATED_TX_STAMP, CREATED_STAMP, CREATED_TX_STAMP) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) (ERROR: deadlock detected))). Rolling back transaction.


at the same time there is a deadlock message in the postgres log.

ERROR:  deadlock detected
DETAIL: Process 7282 waits for ShareLock on transaction 44775520; blocked by process 7283. Process 7283 waits for ShareLock on transaction 44775524; blocked by process 7282.



currently I have no idea why the deadlock occours.

best regards
Sebastian

--On Dienstag, 31. Oktober 2006 11:41 -0700 David E Jones <[EMAIL PROTECTED]> wrote:


Sebastian,

What you're describing does not sound like it has anything to do
withlower level things like transactions.

When payment fails on an order it is still stored, but in a
rejectedstate. Any additional attempts to place the same order again will
beattached to the original order. I'm sure if you look at the
details(like the transaction time stamps on these different orders)
you'llsee that they were placed minutes apart with many transactions
inbetween, and it has nothing to do with anything technical, I'd
guessit's all business level stuff on this one and this is how it
designedto behave.

-David





/**
*  Sebastian Schirmer
*  ZYRES digital media systems GmbH
*  Eschersheimer Landstr. 5-7
*  60322 Frankfurt am Main
*
*  Phone +49 (0)69 98 55 99 - 0 | Fax   +49 (0)69 98 55 99 - 11
*  http://www.zyres.com/
*
*/


Reply via email to