[DRIVERS-2065] Session can be reused after tx abort fails Created: 21/May/19  Updated: 31/Mar/22

Status: Backlog
Project: Drivers
Component/s: Sessions
Fix Version/s: None

Type: Spec Change Priority: Minor - P4
Reporter: Oleg Pudeyev (Inactive) Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Related
Driver Changes: Needed

 Description   

https://github.com/mongodb/specifications/blob/master/source/transactions/transactions.rst#endsession-changes says:

> endSession changes
>
> This method ends a ClientSession. Drivers MUST call abortTransaction if this session is in the "transaction in progress" state in order to release resources on the server. Drivers MUST ignore any errors raised by abortTransaction while ending a session.

In a driver implementing server session pool, endSession returns the session to the pool rather than ends it. The session becomes available for future use.

If a session had a transaction on it, and aborting the transaction failed, should the session still be returned to the pool? I think in this case the session should be discarded.



 Comments   
Comment by Esha Bhargava [ 09/Sep/19 ]

oleg.pudeyev can you talk to Shane and get more details on this or if this is handled by SPEC-1159

Comment by Shane Harvey [ 24/Jun/19 ]

If a session had a transaction on it, and aborting the transaction failed, should the session still be returned to the pool? I think in this case the session should be discarded.

I think the work here is to determine whether an idle transaction on the server can block future operations or have any other undesirable effects. Let's assume server session S is used for a transaction, the abort fails, and the transaction is left open on the server. Let's also assume that the very next operation reuses server session S. From the research in SPEC-1159 I believe the operations that will complete normally are:

  • a non-transactional read
  • a non-transactional write which does not conflict with the transaction's writes
  • an operation that starts a multi-document transaction because it will abort the previous transaction on S.

Operations that will block are:

  • a non-transactional write which conflicts with the transaction's writes will block until the transaction times out because the server internally retries such writes on WriteConflict errors.

Operations I'm not sure of (to be determined):

  • a retryable write. I suspect this will behave the same as an operation that starts a multi-document transaction.
  • DDL operations. create, drop, createIndex, etc. I suspect they will block until the transaction times out.
Comment by Ian Whalen (Inactive) [ 24/Jun/19 ]

shane.harvey can you comment on whether there's remaining work here that must be done prior to a 4.2 compatible release given the work that already landed in SPEC-1159?

Generated at Thu Feb 08 08:24:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.