[SERVER-38015] Confirm transactions don't hold on to tickets Created: 07/Nov/18  Updated: 29/Oct/23  Resolved: 21/Dec/18

Status: Closed
Project: Core Server
Component/s: Concurrency
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Improvement Priority: Major - P3
Reporter: Geert Bosch Assignee: Geert Bosch
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Storage NYC 2018-12-03, Storage NYC 2018-12-17, Storage NYC 2018-12-31
Participants:

 Description   

Currently transactions will obtain a writing ticket as part of their GlobalLock acquisition, and hold on to it for the duration of the transaction. However, if the average transaction takes 1 second because of network or application delays, that would mean you cannot do more than 128 transactions per second, even if the system is almost entirely idle.

A possible solutions could be releasing tickets after the first use.



 Comments   
Comment by Bruce Lucas (Inactive) [ 04/Sep/19 ]

This may already work this way, geert.bosch is going to double check.

It was confirmed that it already worked that way: transactions did not (and do not) hold onto tickets for the duration, and no code changes were implemented for this ticket.

Comment by Githook User [ 21/Dec/18 ]

Author:

{'username': 'GeertBosch', 'email': 'geert@mongodb.com', 'name': 'Geert Bosch'}

Message: SERVER-38015 Test many concurrent transactions
Branch: master
https://github.com/mongodb/mongo/commit/fc0555b28a9a5fbade9b47ac3b6eed17852be301

Comment by Sara Williamson [ 09/Nov/18 ]

This may already work this way, geert.bosch is going to double check.

Comment by Judah Schvimer [ 07/Nov/18 ]

Per discussion with geert.bosch, two other solutions could be:
1) A separate ticket pool for transactions
2) Transactions could release their tickets after their first statement and then acquire a "re-acquisition ticket" from another pool on subsequent statements. This shouldn't lead to deadlocks as long as transactions do not take conflicting locks.

Generated at Thu Feb 08 04:47:43 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.