0003253: Some order numbers stays zero in specially crafted high load situation

ID	Project	Category	View Status	Date Submitted	Last Update

0003253	OXID eShop (all versions)	1.03. Basket, checkout process	public	2011-09-20 08:23	2012-12-10 13:23

Reporter	alfonsas_cirtautas	Assigned To
Priority	high	Severity	crash	Reproducibility	always
Status	resolved	Resolution	fixed
Product Version	4.5.2 revision 38481
Fixed in Version	4.6.0_beta2

Summary	0003253: Some order numbers stays zero in specially crafted high load situation
Description	Create a dedicated view (views/fakeorder.php attached) and run concurrent ab test. ab -n 100 -c 2 http://oxid-eshop/index.php?cl=fakeorder after it is finished, check db select count(*) from oxorder where oxordernr = 0; In my case it was always ~10 orders with order number 0
Tags	Order
Attached Files	fakeorder.php (146 bytes)

Theme	Both
Browser	All
PHP Version	any
Database Version	any

mark 2011-09-20 08:49 reporter ~0005244	See here: https://bugs.oxid-esales.com/view.php?id=2693

dainius.bigelis 2011-09-21 15:39 reporter ~0005256 Last edited: 2011-09-21 15:40	Info from 0002693: Sometimes Orders are generated with oxordernr = 0 and oxshopid = 0. _setRecordNumber() seems not to work properly for orders. Please review all the comments in the entry 0002693 as it may contain useful info for solving the issue.

mark 2011-09-22 12:51 reporter ~0005258	I found something in the coreclass oxOrder. Function_insert tries to set a ordernr: $this->_setRecordNumber( 'oxordernr', $aWhere ); But if the call fails (database max requests e.g.) the return value is ignored. Better would be: $blInsert = $this->_setRecordNumber( 'oxordernr', $aWhere ); Same in the function finalizeOrder $this->save(); should better be if (!$this->save()) { return false; }

Linas Kukulskis 2011-10-11 13:50 reporter ~0005295	changed order number setting mechanism to avoid mysql dead locks. created oxcounter