While reading the PDO documentation, they state:

When the script ends or when a connection is about to be closed, if you have an outstanding transaction, PDO will automatically roll it back. This is a safety measure to help avoid inconsistency in the cases where the script terminates unexpectedly--if you didn't explicitly commit the transaction, then it is assumed that something went awry, so the rollback is performed for the safety of your data.

Today, when the PHP script ends, the Transaction objects destructor will be called, thus forcing a clean autocommit: this is a bad practice in most cases.

Ideally, when the shutdown handler time comes, the non finished transactions should not commit but fail instead. A non commited transaction at script end means that a poorly developed portion of the code or a logic error happened.

Today, I spent 2 hours on debugging transactions, because of Commerce pessimistic locking which actually create one of them as soon as you load at least one order: this means that everything that happens on the site will be isolated in this transaction. They never release it, considering than they are the own of the order, the only case it can be released is if you save it or reset the controller cache. If anything goes wrong and make it fail, the whole page runtime will be a ghost and may disapear (and this also may cause extra cache miss). This is an example, not a bug report, nevertheless, this is a perfect exemple of a terrible transaction usage which can cause serious trouble.

If the database system was able to, at least, extra verbose critical level errors when the shutdown handlers come and transactions are not commited properly, this kind of code in contrib (and potentially in core too) would be easily spotted and naturally fixed as soon as it exists. Best case scenario would be to let the transaction rollback instead, but the critical watchdog messages (even with transaction commit) would be a great help for all developers.

Important: I am NOT saying we should change the auto commit policy on object destruct and change DX, I'm only speaking about the shutdown exception of this policy.

Comments

c960657’s picture

jhedstrom’s picture

While this is marked as a feature request, I think it might still be possible to get into 8.0 given the issue it is addressing would be seen as a bug when encountered.

jhedstrom’s picture

Category: Feature request » Task

I think this is a task (maybe a bug).

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.