For consistency with the change in {commerce_order} done in #1363826: Deadlock issues when saving orders concurrently, we should not use 0 as the default value for revision_id of {commerce_payment_transaction} and {commerce_customer_profile}.

This avoids the database from having to obtain a gap lock at the beginning of the unique key, thus increasing the concurrency in some types of load.

Files: 
CommentFileSizeAuthor
#3 1804518-3.revision_id_default_values.patch4.73 KBrszrama
PASSED: [[SimpleTest]]: [MySQL] 3,551 pass(es).
[ View ]
#2 1804518-avoid-unnecessary-lock-revision-id.patch4.07 KBDamien Tournoud
PASSED: [[SimpleTest]]: [MySQL] 3,551 pass(es).
[ View ]
1804518-avoid-unnecessary-lock-revision-id.patch5.06 KBDamien Tournoud
PASSED: [[SimpleTest]]: [MySQL] 3,551 pass(es).
[ View ]

Comments

StatusFileSize
new4.07 KB
PASSED: [[SimpleTest]]: [MySQL] 3,551 pass(es).
[ View ]

Untested patch. The change in {commerce_product} is purely for consistency. It's a non-operation and as a consequence doesn't need an update function.

StatusFileSize
new4.73 KB
PASSED: [[SimpleTest]]: [MySQL] 3,551 pass(es).
[ View ]

Was about to commit the attached (fixed the calls to db_change_field()) when I reread your comment and saw you intentionally didn't update commerce_product. Not entirely sure what you mean by it being a "non-operation" - any site created using Commerce 1.2 or 1.3 would have a default value of 0 still set for the revision_id column on that table, just not those that updated from 1.1 or earlier to 1.2 or later.

Did you leave it out for performance concerns or should I just commit my update as is?

Status:Needs review» Fixed

Committed.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.