Change Details

Below I'll explain how I've replicated racing condition. Feel free to use other preferred method if needed. == in Admin Console: == * create a tangible product == in PhpStorm == * enable debugger * make sure that parallel debug is enabled: {F41161} * put breakpoint on the line where `LOCK ...` statement is in changed code == on Front-End == # open 2 browser tabs (one normal and one private so that cookies are not shared) # in each tab: * go to category category where product as added * enable Xdebug * press `Buy Now` button # confirm, that 2 debug connections were created in PhpStorm # allow the `LOCK ...` sql to be executed in 1st debug session # allow the `LOCK ...` sql to be executed in 2nd debug session # confirm, that in 2nd debug session debugging is impossible due attempt of lock tables, that are already locked # let code from both debug sessions be executed till the end # confirm, that: * both created orders have different `Number` column value * the value of `Comm_Next_Order_Number` system setting (in {nav Configuration > E-commerce > General} section) has next available order number (+1 then last used one)

Below I'll explain how I've replicated racing condition. Feel free to use other preferred method if needed. == in Admin Console: == * create a tangible product * create an Incomplete order (can be without products as well) * go to {nav Configuration > E-commerce > General} section * confirm, that `Comm_Next_Order_Number` system setting value is `2` (if you've created orders before it will be last order number plus one) * try entering larger value (e.g. 5) * confirm, that value is saved * try entering lower value (lower, than last created order number) * confirm, that validation error is shown exposing actual minimal value that can be entered in that field == in PhpStorm == * enable debugger * make sure that parallel debug is enabled: {F41161} * put breakpoint on the line where `LOCK ...` statement is in changed code == on Front-End == # open 2 browser tabs (one normal and one private so that cookies are not shared) # in each tab: * go to category category where product as added * enable Xdebug * press `Buy Now` button # confirm, that 2 debug connections were created in PhpStorm # allow the `LOCK ...` sql to be executed in 1st debug session # allow the `LOCK ...` sql to be executed in 2nd debug session # confirm, that in 2nd debug session debugging is impossible due attempt of lock tables, that are already locked # confirm, that you can open any of Configuration section (that read from `SystemSettings` table) in the Admin Console # let code from both debug sessions be executed till the end # confirm, that: * both created orders have different `Number` column value * the value of `Comm_Next_Order_Number` system setting (in {nav Configuration > E-commerce > General} section) has next available order number (+1 then last used one)

Below I'll explain how I've replicated racing condition. Feel free to use other preferred method if needed. == in Admin Console: == * create a tangible product * create an Incomplete order (can be without products as well) * go to {nav Configuration > E-commerce > General} section * confirm, that `Comm_Next_Order_Number` system setting value is `2` (if you've created orders before it will be last order number plus one) * try entering larger value (e.g. 5) * confirm, that value is saved * try entering lower value (lower, than last created order number) * confirm, that validation error is shown exposing actual minimal value that can be entered in that field == in PhpStorm == * enable debugger * make sure that parallel debug is enabled: {F41161} * put breakpoint on the line where `LOCK ...` statement is in changed code == on Front-End == # open 2 browser tabs (one normal and one private so that cookies are not shared) # in each tab: * go to category category where product as added * enable Xdebug * press `Buy Now` button # confirm, that 2 debug connections were created in PhpStorm # allow the `LOCK ...` sql to be executed in 1st debug session # allow the `LOCK ...` sql to be executed in 2nd debug session # confirm, that in 2nd debug session debugging is impossible due attempt of lock tables, that are already locked # confirm, that you can open any of Configuration section (that read from `SystemSettings` table) in the Admin Console # let code from both debug sessions be executed till the end # confirm, that: * both created orders have different `Number` column value * the value of `Comm_Next_Order_Number` system setting (in {nav Configuration > E-commerce > General} section) has next available order number (+1 then last used one)