Info

I'm trying to test how drivers will handle error cases within multi-statement transactions. I perform the following with my prototype of PyMongo that supports transactions: session = client.start_session() session.start_transaction() collection.insert_one({'_id': 1}, session=session) try: collection.insert_one({'_id': 1}, session=session) except Exception as exc: print(exc) collection.insert_one({'_id': 1}, session=session) session.commit_transaction() It appears (based on debugging) that the transaction includes the document {_id: 1} after the first insert, and the second insert not only causes a duplicate key error, it also aborts the transaction. Therefore the third insert succeeds (outside of any transaction), and the commit_transaction fails with code 125, errmsg "Transaction isn't in progress."

Top User Comments

greg.mckeon commented on Tue, 19 Jun 2018 18:24:49 +0000: This is currently not possible to fix in the storage engine. jesse commented on Mon, 26 Mar 2018 21:23:16 +0000: I've opened DOCS-11493 to at least write down all the errors that abort a transaction. siyuan.zhou@10gen.com commented on Fri, 23 Mar 2018 20:39:33 +0000: I had a patch last night to allow DuplicatedKey error, but it turns out we cannot. DuplicatedKey error is checked as a part of a WUOW after the data write, the convention is to uassert and abort the WT transaction. If we keep the WT transaction and reuse it, the document will be preserved in the data table. DuplicatedKey error is just one example. Any index constraints will result in the same issue, e.g. inserting unexpected location format into geo index. spencer commented on Fri, 23 Mar 2018 15:22:43 +0000: The latter issue about the third write being performed outside the transaction will be fixed by SERVER-34051 spencer commented on Fri, 23 Mar 2018 15:20:54 +0000: This is related to the work on SERVER-33432, and can probably be completed concurrently to it. We should have a set of error codes that cause implicit transaction abort, and otherwise we should leave the transaction in place. jesse commented on Thu, 22 Mar 2018 17:11:47 +0000: It's from a server behavior. The driver appears to be doing the right thing: same lsid and txnNumber as the previous inserts, and a stmtId that is one greater. The server has forgotten about the transaction, though, so I guess it thinks this is a retryable write, and it succeeds. schwerin commented on Thu, 22 Mar 2018 13:05:21 +0000: It's also worrisome that the server thought the third insert was outside a transaction. Is that from a server or driver behavior?

Steps to Reproduce