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.

CommentFileSizeAuthor
#3 1804518-3.revision_id_default_values.patch4.73 KBrszrama
#2 1804518-avoid-unnecessary-lock-revision-id.patch4.07 KBdamien tournoud
1804518-avoid-unnecessary-lock-revision-id.patch5.06 KBdamien tournoud

Comments

damien tournoud’s picture

damien tournoud commented
StatusFileSize
new 1804518-avoid-unnecessary-lock-revision-id.patch4.07 KB

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.

rszrama’s picture

rszrama commented
StatusFileSize
new 1804518-3.revision_id_default_values.patch4.73 KB

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?

rszrama’s picture

rszrama commented
Status: Needs review » Fixed

Committed.

Status: Fixed » Closed (fixed)

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