Yes SMO's happen in nested transactions and commit separately from the transaction that initiated the split. Once the split is committed is stays, even if the transaction which caused the split decides to abort.
Dibyendu Majumdar wrote: > Mike Matrigali wrote: > >> As you note undo of structural changes are >> physical. So at the high level recovery goes as follows: >> >> Find the oldest log record that needs to be looked at. >> Go forward from that point and redo each record in log file >> (if version of page is later than log record then no work to do) >> Undo all nested top transactions which must only require physical undo, >> which are basically structural changes >> like btree split and/or page allocations. Now all tree structures >> are intact so that logical undo is possible. > > > Mike, > > About structural changes - I assume that only incomplete structural > changes are undone? If a structural change is complete, then even if the > transaction that caused that structural change aborts, there should be > no need to undo the structural change itself, although the key insert/or > delete has to be obviously undone. > > If this is not the case, then how does Derby handle the situation where > a structural change has been made, and subsequently other transactions > have made more changes, and then the original transaction that made the > structural change, decides to abort? > > Regards > > Dibyendu > >
