Nested Transactions

[mrackwitz]

Allow to start a new nested write transaction within an already open write transaction.

• When a nested transaction is committed, the modifications should only propagate to next outer transaction.
• When the inner transaction is rolled back, only the modifications of that inner transaction should be discarded and the modifications of any previous nested transactions as well as the previous modifications in the outer transaction should remain.
• When an outer transaction is rolled back, then all modifications of all inner transactions should be discarded.

[cmelchior]

Android issue for this: https://github.com/realm/realm-java/issues/1509

[mrackwitz]

Cocoa issue for this: https://github.com/realm/realm-cocoa/issues/2502

[finnschiermer]

Implementation Idea: extend existing machinery to buffer multiple transactions before "physical" commit. We need to a) be able to rollback multiple transactions to get the accessors correctly updated b) save freelists, toprefs and baselines on a stack for each nested transaction start c) restore on transaction rollback d) reuse current copy-on-write machinery by moving "baseline" for each nested transaction e) don't merge changes when multiple nested transactions commit, instead consider them as multiple distinct transactions, when it comes to numbering and log generation. f) BUT (to ensure durability) write all the transactions without syncing/flipping top pointers between each one. Only do that in the end.

[simonask]

It seems that there are also two separate use cases in play, and I have no idea what the implications are of each or whether they automatically collapse, but they are:

• Nested transactions where transactions are committed from innermost to outermost, and
• Nested transactions where transactions are committed from outermost to innermost (chain).

Furthermore, it seems that a natural requirement to impose is that a transaction with subtransactions may not be modified after starting a subtransaction, potentially even if that subtransaction has been rolled back.

[finnschiermer]

I'm not sure I understand. It doesn't make sense to commit something which has a nested uncommitted transaction, does it? So commit must always occur from the inside out. What am I missing?

[simonask]

If instead of real nesting you just have a chain of transactions where you want to set "checkpoints" on the way, but always commit things to the database in order according to when the transaction was started (in a FIFO manner), that seems to be a clear use case :)

[finnschiermer]

Ok, I'll call that pipelined commits. I think we can support both with the same underlying machinery. Mostly.