[SERVER-37837] Possible for TransactionParticipant to never get cleaned up if no write happened Created: 30/Oct/18 Updated: 29/Oct/23 Resolved: 17/May/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 4.1.4 |
| Fix Version/s: | 4.1.12, 4.0.13 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Kaloian Manassiev |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||
| Sprint: | Sharding 2018-12-31, Sharding 2019-03-25, Sharding 2019-05-06, Sharding 2019-05-20 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
If a TransactionParticipant was created but never successfully persisted any changes to config.transactions, it can stay alive indefinitely. The most likely case for this to occur is when session is exclusively used for read only transactions. This is because the transaction reaper only looks at the config.transactions collection when deciding which transactions to reap. |
| Comments |
| Comment by Kaloian Manassiev [ 04/Oct/19 ] |
|
This relates to retryable writes as well. For example, if the session of a retryable write which resulted in a no-op (didn't generate an oplog entry) was abandoned, the in-memory session state will not be cleaned-up. |
| Comment by Githook User [ 28/Sep/19 ] |
|
Author: {'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev'}Message: |
| Comment by Githook User [ 27/Sep/19 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: Part 1: This change gets rid of the TransactionReaper's usage of the It also removes the TransactionReaper's grouping per-shard optimization (cherry picked from commit 2791817876636c0cfd60d867f31c7a83cf3f18c1) Part 2: This change folds the TransactionReaper's single function to be part of (cherry picked from commit 94f269a1c6053824c4dabc50e8c9219b80a6a1b5) |
| Comment by Githook User [ 05/Sep/19 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: (cherry picked from commit dabbf059e6f96edb4898b42d532d460efd2510f2) |
| Comment by Githook User [ 17/May/19 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: This change makes the logical sessions cache query and reap sessions, |
| Comment by Githook User [ 09/May/19 ] |
|
Author: {'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}Message: |
| Comment by Githook User [ 09/May/19 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: This change folds the TransactionReaper's single function to be part of |
| Comment by Githook User [ 09/May/19 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: This change gets rid of the TransactionReaper's usage of the It also removes the TransactionReaper's grouping per-shard optimization |
| Comment by Githook User [ 07/May/19 ] |
|
Author: {'name': 'Kaloian Manassiev', 'username': 'kaloianm', 'email': 'kaloian.manassiev@mongodb.com'}Message: |
| Comment by Githook User [ 02/May/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}Message: |
| Comment by Githook User [ 02/May/19 ] |
|
Author: {'name': 'Gregory Wlodarek', 'username': 'GWlodarek', 'email': 'gregory.wlodarek@mongodb.com'}Message: |
| Comment by Githook User [ 02/May/19 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: |
| Comment by Gregory McKeon (Inactive) [ 09/Nov/18 ] |
|
This also applies for TransactionRouter. |
| Comment by Kaloian Manassiev [ 01/Nov/18 ] |
|
This applies to 4.0 as well, right? And now to think of it - is it a problem in 3.6 as well, isn't it? If a no-op write executes, it is not going to write anything to config.transactions, but the in-memory object will remain. Meaning if the session is abandoned it will forever remain in-memory. |
| Comment by Randolph Tan [ 31/Oct/18 ] |
|
After talking with Siyuan offline, realized that this is easier to hit than originally thought, updated description to mention read only transactions. |
| Comment by Siyuan Zhou [ 31/Oct/18 ] |
|
The session reaper is different from transaction reaper. Session reaper looks up the session table and destroys the expired sessions. Since transaction participant is a decoration on session, it should be destroyed then. |
| Comment by Randolph Tan [ 31/Oct/18 ] |
|
siyuan.zhou The transaction reaper only looks at config.transactions, so if there's no corresponding entry in there, then it doesn't exist from the point of view of the reaper. |
| Comment by Siyuan Zhou [ 30/Oct/18 ] |
|
Does the session reaper kill this transaction participant? |