From customer:
--------------------------------------
Orders with order_nr=0, is_temporary=1

We've had three instances of this so far, out of about 5,000 placed orders since October 2010. The customer completes the order, and it looks from their end like things worked. But the order number doesn't get assigned (stays 0) and is_temporary remains set at 1, and the e-mail field doesn't get populated. In short, $order->activate(); fails. The affected orders are rendered "permanently temporary". They don't show up on the Webshop tab, and when they dump into our ERP they misbehave because of the non-unique order_nr. Our research on the problem has raised a question about the transaction architecture, specifically whether the PHP code should be locking ezorder when it's an InnoDB table.

The function that changes orders from temporary calls $db->lock('ezorder'). That's an InnoDB table, and from what I read in the MySQL manual and also from InnoDB itself it's not advisable to use table-level locking with InnoDB. Is this something leftover in eZ Pub from the MyISAM days?
--------------------------------------

Steps to reproduce

No pattern identified based on the three data points we have. Affected three different users, two of whom have multiple successful orders in the system. No products in common across affected orders. Events took place weeks or months apart.