Conversation
This reverts commit 62915a5.
| // we have two different transactions attempting to update the same collection. | ||
| // Here, we manually keep track of the collections involved in transactions, so that | ||
| // we can avoid this deadlock. | ||
| var isLocked = this._lockedCollections[collectionName] && |
There was a problem hiding this comment.
As I mentioned in share/sharedb#689 (comment) this locking complexity may be removed entirely if we follow MongoDB's own behaviour and define cross-transactional, awaited writes to the same document to be undefined behaviour. Instead, if we just let them run in parallel, MongoDB and ShareDB can do their thing.
| // Here, we manually keep track of the collections involved in transactions, so that | ||
| // we can avoid this deadlock. | ||
| var isLocked = this._lockedCollections[collectionName] && | ||
| this._lockedCollections[collectionName] !== options.transaction; |
There was a problem hiding this comment.
NB: if we keep this behaviour (I don't think we should), I think MongoDB locks on a document level, so we should update this key to collectionName + id to avoid unnecessary locking.
| // current transaction | ||
| // TODO: Wait for this? | ||
| this.abortTransaction(this._lockedCollections[collectionName], function(error) { | ||
| // TODO: Handle errors |
There was a problem hiding this comment.
I'm not really sure what to do with this error, and this feels like a bit of a code smell in the architecture of transactions.
| this._transactionOpLinks[transactionId] = []; | ||
| var session = this._sessions[transactionId] = this._mongoClient.startSession(); | ||
| session.startTransaction(); |
There was a problem hiding this comment.
One thing that possibly should be noted in docs, is that mongo db transactions require replica sets. They won't work on single instance.
2 participants
No description provided.