is the current trunk version stable enough for an e-commerce project?

[Sebastian Schirmer]

Hi,

Is the current trunk version stable enough for a consumer ecommerce
project? Last year we made an ecommerce project using the sequoiaerp-0.8.0
version with good results (http://www.vector.tv).


best Regards
Sebastian

/**
 *  Sebastian Schirmer
 *  ZYRES digital media systems GmbH
 *  Eschersheimer Landstr. 5-7
 *  60322 Frankfurt am Main
 *
 *  Phone [phone] - 0 | Fax   [phone] - 11
 *  http://www.zyres.com/
 *
 */

[Jacques Le Roux]

Yes I think so

Jacques

----- Original Message -----
From: "Sebastian Schirmer" <[hidden email]>
To: <[hidden email]>
Sent: Monday, October 30, 2006 9:59 AM
Subject: is the current trunk version stable enough for an e-commerce project?

> Hi,
>
> Is the current trunk version stable enough for a consumer ecommerce
> project? Last year we made an ecommerce project using the sequoiaerp-0.8.0
> version with good results (http://www.vector.tv).
>
>
> best Regards
> Sebastian
>
> /**
>  *  Sebastian Schirmer
>  *  ZYRES digital media systems GmbH
>  *  Eschersheimer Landstr. 5-7
>  *  60322 Frankfurt am Main
>  *
>  *  Phone [phone] - 0 | Fax   [phone] - 11
>  *  http://www.zyres.com/
>  *
>  */

[Tim Ruppert]

We've been very successful using the trunk and customizing our own
application in hot-deploy.  I believe it's stable enough.

Cheers,
Tim

--
Tim Ruppert
HotWax Media
http://www.hotwaxmedia.com

o:801.649.6594
f:801.649.6595

Sebastian Schirmer wrote:

> Hi,
>
> Is the current trunk version stable enough for a consumer ecommerce
> project? Last year we made an ecommerce project using the
> sequoiaerp-0.8.0 version with good results (http://www.vector.tv).
>
>
> best Regards
> Sebastian
>
> /**
> *  Sebastian Schirmer
> *  ZYRES digital media systems GmbH
> *  Eschersheimer Landstr. 5-7
> *  60322 Frankfurt am Main
> *
> *  Phone [phone] - 0 | Fax   [phone] - 11
> *  http://www.zyres.com/
> *
> */

[Sebastian Schirmer]

Hi,

thanks for your response. Have you expieriences with ofbiz and heavy load?
We have sometimes deadlocks on the postgres database. The effects are
duplicate orders because ofbiz stores the same order with a new order id.

best regards
Sebastian

--On Montag, 30. Oktober 2006 05:23 -0700 Tim Ruppert
<[hidden email]> wrote:

> We've been very successful using the trunk and customizing our own
> application in hot-deploy.  I believe it's stable enough.
>
> Cheers,
> Tim
>
> --
> Tim Ruppert
> HotWax Media
> http://www.hotwaxmedia.com
>
> o:801.649.6594
> f:801.649.6595
>
> Sebastian Schirmer wrote:
>> Hi,
>>
>> Is the current trunk version stable enough for a consumer ecommerce
>> project? Last year we made an ecommerce project using the
>> sequoiaerp-0.8.0 version with good results (http://www.vector.tv).
>>
>>
>> best Regards
>> Sebastian
>>
>> /**
>> *  Sebastian Schirmer
>> *  ZYRES digital media systems GmbH
>> *  Eschersheimer Landstr. 5-7
>> *  60322 Frankfurt am Main
>> *
>> *  Phone [phone] - 0 | Fax   [phone] - 11
>> *  http://www.zyres.com/
>> *
>> */

/**
 *  Sebastian Schirmer
 *  ZYRES digital media systems GmbH
 *  Eschersheimer Landstr. 5-7
 *  60322 Frankfurt am Main
 *
 *  Phone [phone] - 0 | Fax   [phone] - 11
 *  http://www.zyres.com/
 *
 */

[Jacques Le Roux]

Not a problem of time out too short for transactions ?

Jacques

> Hi,
>
> thanks for your response. Have you expieriences with ofbiz and heavy load?
> We have sometimes deadlocks on the postgres database. The effects are
> duplicate orders because ofbiz stores the same order with a new order id.
>
> best regards
> Sebastian
>
> --On Montag, 30. Oktober 2006 05:23 -0700 Tim Ruppert
> <[hidden email]> wrote:
>
> > We've been very successful using the trunk and customizing our own
> > application in hot-deploy.  I believe it's stable enough.
> >
> > Cheers,
> > Tim
> >
> > --
> > Tim Ruppert
> > HotWax Media
> > http://www.hotwaxmedia.com
> >
> > o:801.649.6594
> > f:801.649.6595
> >
> > Sebastian Schirmer wrote:
> >> Hi,
> >>
> >> Is the current trunk version stable enough for a consumer ecommerce
> >> project? Last year we made an ecommerce project using the
> >> sequoiaerp-0.8.0 version with good results (http://www.vector.tv).
> >>
> >>
> >> best Regards
> >> Sebastian
> >>
> >> /**
> >> *  Sebastian Schirmer
> >> *  ZYRES digital media systems GmbH
> >> *  Eschersheimer Landstr. 5-7
> >> *  60322 Frankfurt am Main
> >> *
> >> *  Phone [phone] - 0 | Fax   [phone] - 11
> >> *  http://www.zyres.com/
> >> *
> >> */
>
>
>
> /**
>  *  Sebastian Schirmer
>  *  ZYRES digital media systems GmbH
>  *  Eschersheimer Landstr. 5-7
>  *  60322 Frankfurt am Main
>  *
>  *  Phone [phone] - 0 | Fax   [phone] - 11
>  *  http://www.zyres.com/
>  *
>  */

[Sebastian Schirmer]

Hi Jacques,

thanks for your hints. I suggest the order creation is done by a service? I
saw in the duplicate order data record is the the intital id mentioned. But
I have the postgres also under suspicion. Currently we can´t change to
Postgres 8.1 because the database is maintained by an other supplier. We
uses the postgresql-8.0-311.jdbc3.jar with PostgreSQL 7.4.13.


best Regards
Sebastian




--On Montag, 30. Oktober 2006 20:59 +0100 Jacques Le Roux
<[hidden email]> wrote:

> Sebastian
>
> You can set the transaction timeout in different places:
>
> - as an attribute of screen definition : this sets the timeout of the
> screen's transaction - as an attribute of a service definition : this
> sets the timeout of the service
>
> First of all I'd try with the latter...
>
> Also BTW I read that there was some problems with pre PostGres 8.0 JDBC
> drivers.  I'd try to move to PostGres 8.1
>
> Jacques
>
>
>> --On Montag, 30. Oktober 2006 19:09 +0100 Jacques Le Roux
>> <[hidden email]> wrote:
>>
>> > Not a problem of time out too short for transactions ?
>>
>> Hi,
>>
>> where to adjust? The system is working on a postges 7.4.3
>>
>>
>> best regards
>> Sebastian
>>
>> /**
>>  *  Sebastian Schirmer
>>  *  ZYRES digital media systems GmbH
>>  *  Eschersheimer Landstr. 5-7
>>  *  60322 Frankfurt am Main
>>  *
>>  *  Phone [phone] - 0 | Fax   [phone] - 11
>>  *  http://www.zyres.com/
>>  *
>>  */

/**
 *  Sebastian Schirmer
 *  ZYRES digital media systems GmbH
 *  Eschersheimer Landstr. 5-7
 *  60322 Frankfurt am Main
 *
 *  Phone [phone] - 0 | Fax   [phone] - 11
 *  http://www.zyres.com/
 *
 */

[David E Jones-2]

Sebastian,

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

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

-David


On Oct 31, 2006, at 2:19 AM, Sebastian Schirmer wrote:

> Hi Jacques,
>
> thanks for your hints. I suggest the order creation is done by a  
> service? I saw in the duplicate order data record is the the  
> intital id mentioned. But I have the postgres also under suspicion.  
> Currently we can´t change to Postgres 8.1 because the database is  
> maintained by an other supplier. We uses the  
> postgresql-8.0-311.jdbc3.jar with PostgreSQL 7.4.13.
>
>
> best Regards
> Sebastian
>
>
>
>
> --On Montag, 30. Oktober 2006 20:59 +0100 Jacques Le Roux  
> <[hidden email]> wrote:
>
>> Sebastian
>>
>> You can set the transaction timeout in different places:
>>
>> - as an attribute of screen definition : this sets the timeout of the
>> screen's transaction - as an attribute of a service definition : this
>> sets the timeout of the service
>>
>> First of all I'd try with the latter...
>>
>> Also BTW I read that there was some problems with pre PostGres 8.0  
>> JDBC
>> drivers.  I'd try to move to PostGres 8.1
>>
>> Jacques
>>
>>
>>> --On Montag, 30. Oktober 2006 19:09 +0100 Jacques Le Roux
>>> <[hidden email]> wrote:
>>>
>>> > Not a problem of time out too short for transactions ?
>>>
>>> Hi,
>>>
>>> where to adjust? The system is working on a postges 7.4.3
>>>
>>>
>>> best regards
>>> Sebastian
>>>
>>> /**
>>>  *  Sebastian Schirmer
>>>  *  ZYRES digital media systems GmbH
>>>  *  Eschersheimer Landstr. 5-7
>>>  *  60322 Frankfurt am Main
>>>  *
>>>  *  Phone [phone] - 0 | Fax   [phone] - 11
>>>  *  http://www.zyres.com/
>>>  *
>>>  */
>
>
>
> /**
> *  Sebastian Schirmer
> *  ZYRES digital media systems GmbH
> *  Eschersheimer Landstr. 5-7
> *  60322 Frankfurt am Main
> *
> *  Phone [phone] - 0 | Fax   [phone] - 11
> *  http://www.zyres.com/
> *
> */
>

[Sebastian Schirmer]

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,[hidden email](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,[hidden email](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
<[hidden email]> 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 [phone] - 0 | Fax   [phone] - 11
 *  http://www.zyres.com/
 *
 */

[David E Jones-2]

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,[hidden email](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,[hidden email](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  
> <[hidden email]> 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 [phone] - 0 | Fax   [phone] - 11
> *  http://www.zyres.com/
> *
> */
>

[Sebastian Schirmer]

Hi David,

Thanks. We have a simple submit button on the confirm page. The java script
may help. but I have seen the error on a single submit too(difficult to
reproduce because the problem occurs only sometimes). We try a migration to
postgres 8.1. It may help.

best regards
Sebastian

--On Mittwoch, 1. November 2006 10:47 -0700 David E Jones
<[hidden email]> wrote:

>
> Interesting... perhaps this is caused by double-clicking on thesubmit
> order button?
>
> There is some JavaScript that disables the button after it is clickedto
> 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,[hidden email](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,[hidden email](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
>> <[hidden email]> 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 [phone] - 0 | Fax   [phone] - 11
>> *  http://www.zyres.com/
>> *
>> */
>>
>

/**
 *  Sebastian Schirmer
 *  ZYRES digital media systems GmbH
 *  Eschersheimer Landstr. 5-7
 *  60322 Frankfurt am Main
 *
 *  Phone [phone] - 0 | Fax   [phone] - 11
 *  http://www.zyres.com/
 *
 */