[TYPO3-commerce] Duplicated orders in database!!!

[Bert Hiddink [BENDOO e-work solutions]]

Hello Ingo,

Thanks for your reply.

On 3/10/10 4:22 PM, Ingo Schmitt wrote:
> Hi Bert,
>
> if your database has good power, you could rewrite the code.

I think the hardware is not a problem and the database server neither so 
I'll give it a try.

> We had a similar problem, this was caused from a malfunction of the payment provider, which send us orders more than one time. Did you check this?

The problem occurs not only when using the external Payment Gateway (aka 
"iDEAL") but also when using "debit" or "invoice" where no external 
gateway is involved. But I was thinking, if it is because of impatient 
customers hitting the submit button several times, than a javascript 
("freeze button after one submit") should also help, isn't it? What do 
you think?

Thanks and regards!

Bert


> Regards
>
> ingo
>> Hello Morten,
>>
>> Thanks for your replies!
>>
>> If the problem were due to the file-problem, mentioned in your first reply, as far as I can see, a quick fix would be to rewrite the function "getNewId()" in "com_ordernumber" to:
>>
>> /**
>> * Returns  a new id from database
>> * @return 	integer	Oredrnumer
>> */
>> function getNewId()	{
>> 	$newid = $this->getNewIdFromDB();
>> 	return $newid;
>> }
>>
>> In that way, new ordernumbers are always retrieved from the db instead from a file.
>>
>> However, reading from your second reply, I get the impression that this would not help. How to prevent this problem then? Haven't other users reported this issue? Or are we alone on this due to heavy server load?
>>
>> Thanks in advance for your reply!
>>
>> Regards,
>>
>> Bert
>>
>>
>>
>>
>> On 3/10/10 3:25 PM, Morten Olesen wrote:
>>> Hi Bert (again),
>>>
>>> Seems I was a little too quick to reply and jumped the gun, the problem
>>> of 1 order having multiple order numbers is due to server load and
>>> impatient users refreshing on the last step where the order is created.
>>>
>>> The creation of an order is not a transaction either, so it's possible (
>>> even easy given enough load on the server ) to have multiple attempts to
>>> create the order succeed.
>>>
>>> Normally the order is created so fast that it's not a problem, all
>>> subsequent requests will result in no extra orders ( since the session
>>> info, basket, etc have been converted from a paid basket to an order )
>>>
>>> Hope this helps.
>>>
>>> Morten Olesen wrote:
>>>> Hi Bert,
>>>>
>>>> you should _really_ write you own order number generator,
>>>> "com_ordernumber" is a working example at best.
>>>>
>>>> Your duplicate orders is due to it using a file ( in /tmp/domainname
>>>> if memory serves ) rapid access will give you the "bankers problem";
>>>>
>>>> file [ 1000 ]
>>>>
>>>> Thread A: read file ( 1000 )
>>>> Thread B: read file ( 1000 )
>>>> Thread A: increment order number ( 1001 ) and write
>>>> Thread B: increment order number ( 1001 ) and write
>>>>
>>>> file [ 1001 ]
>>>>
>>>> To solve it you need to make sure that the order generator is ACID,
>>>> the easiest way is to make a ordernr table with auto increment on the
>>>> key.
>>>>
>>>>
>>>>
>>>> /Morten
>>>>
>>>> Bert Hiddink [BENDOO e-work solutions] wrote:
>>>>> Hello,
>>>>>
>>>>> I am running a Commerce-shop with TYPO3 4.3.1, added
>>>>> "com_ordernumber" for "friendly" ordernumbers and an extra extension
>>>>> we wrote to apply some hooks. We offer 3 paymentmethods: debit, iDeal
>>>>> and invoice. We use the Commerce SVN-version of December 2009.
>>>>>
>>>>> During testing-fase, everything worked fine but as soon as we put it
>>>>> into production, we noticed that around 1-2% of the orders get
>>>>> duplicated in the database, that is, the customer makes 1 order but
>>>>> this gets registrated in the database as 2, 3 or 4 different orders,
>>>>> each with a unique ordernumber. Only the latest order (highest
>>>>> ordernumber) is send to the customer per email.
>>>>>
>>>>> As you will understand, this makes ordermanagement quite messy: we
>>>>> have to look for duplicates by hand and then remove them.
>>>>>
>>>>> What could be wrong here? I really do not understand why this
>>>>> happens? How to debug?
>>>>>
>>>>> Some extra comments:
>>>>>
>>>>> *) The shop was heavily visited just after launch (3-4 orders per
>>>>> minute), more then 1000 orders during the first day. Could this be a
>>>>> reason?
>>>>>
>>>>> *) On the page were the basket is installed, we had to set it to "No
>>>>> cache" due to some strange caching behaviour?
>>>>>
>>>>> *) How heavily Commerce depends of cookies and/or js being enabled?
>>>>>
>>>>> As you notice, the above are just some guesses since I do not see a
>>>>> clear pattern between cause and consequence.
>>>>>
>>>>> Any idea on this would be highly appreciated.
>>>>>
>>>>> Thanks and regards,
>>>>>
>>>>> Bert Hiddink
>>>>> BENDOO
>>
>> _______________________________________________
>> TYPO3-project-commerce mailing list
>> TYPO3-project-commerce at lists.typo3.org
>> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-commerce
>>
>>
>
>
> Mit freundlichen Gruessen
> Ingo Schmitt
>