Good day, I have a proposal to enhance the transaction handling logic in TP, specifically regarding nested transaction calls, which are common in EE development, particularly when utilizing OGM.
Currently, calling open multiple times causes an exception. This behavior is restrictive, and the term "open" can be confusing. I propose a design that improves the developer experience by using an internal counter for transaction calls: Proposed transaction counter logic 1. begin/commit counter: - begin would increment an internal counter. - commit would decrement the internal counter, causing the actual transaction commit only when the counter reaches zero. 2. rollback behavior: - rollback would immediately force a transaction rollback and decrements the internal counter - the subsequent calls to rollback on the same transaction object should be allowed until the stack trace reaches the initial begin method call, after which further rollback calls would throw an exception. 3. Error handling: - A commit without a matching begin (e.g., counter is already zero) should throw an exception. - A rollback without a matching begin should throw an exception I would also consider hiding the Transaction object altogether and delegating the logic of transaction management to GraphTraversalSource it will simplify the API a lot, both for users and vendors. I also propose to restrict transaction scope to the thread scope, it will be a common denominator that will not harm user experience but will ensure uniform and expected API behavior across all implementations. Proposed API changes - I propose deprecating open and using begin with the semantics described above to avoid confusion. - Transaction object is deprecated, and TX control functionality is delegated to the GraphTraversal/Graph instances. - tx() method is deprecated. - Transaction scope is limited to the current thread only. Behavior for non-direct calls When begin/commit/rollback methods are not called directly, the transaction should be automatically committed by a terminal operation (e.g., when hasNext returns false) in both remote and embedded modes. Implementation notes: 1. The begin command should be added. Relying on the implicit start of TX by traversal can lead to non-controlled side effects. 2. For the sake of optimization of the remote protocol, while multiple calls of begin/commit/rollback are allowed in the remote protocol, practically, it will mean that we will track the counter locally on the client and will send begin/commit/rollback only once for the TX lifecycle. This model should be uniform across all deployment types. What are your thoughts on this approach? ----- Andrii Lomakin YouTrackDB development lead
