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

Ingo Schmitt is at marketing-factory.de
Wed Mar 10 16:22:14 CET 2010


Hi Bert,

if your database has good power, you could rewrite the code. 

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?

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

-- 
Marketing Factory Consulting GmbH  *   mailto:is at marketing-factory.de
Stephanienstrasse 36               *          Tel.: +49 211-361176-63
D-40211 Duesseldorf, Germany       *          Fax:  +49 211-361176-99
Amtsgericht Duesseldorf HRB 53971  * http://www.marketing-factory.de/

Geschaeftsfuehrer:    Peter Faisst   |   Katja Faisst
Karoline Steinfatt   |   Christoph Allefeld   |   Markus M. Kimmel



More information about the TYPO3-project-commerce mailing list