Ann, thanks for taking an interest.

The semantics I would expect from nested transactions are as follows:

(At the global database level)
- A transaction is truly committed if it has committed and all parent transactions have committed.
- A transaction is truly rolled back if it has rolled back or any of its parent transactions have
rolled back.

(If parent transactions are still active, then sub-transactions may have some of these properties,
but aren't finalized.)

- Sub-transactions would have the same isolation properties relative to each other and their parent
transaction as concurrent transactions have to each other and the state of the database (outside of
any transaction) ... yes, sub-transactions could deadlock.

I would expect sub-transactions to see everything their parent transaction(s) did up until the
spawning point, and I would expect parent transactions to see everything their sub-transactions
have done once they've committed (rejoining the parent, thus acting as if the parent has performed
those actions directly)

I would expect the global database level (and new top-level transactions) to potentially (based on
isolation level) see changes by sub-transactions only once those sub-transactions' top-level
transactions had committed.

I would expect that the order of sub-transactions would be irrelevant (in the same sense as
concurrent transactions don't have an order per-se): multiple sub-transactions could be started
simultaneously, without previous sub-transactions having finalized yet. I think of save-points as
sequential along the path of actions by a transaction, allowing you to back up to any point along
that linear path. Am I wrong in that respect? If so, then we're a lot closer than I thought.

I don't think I'd ask for the split/join semantics I've seen mentioned in some papers. (Merging two
random transactions could be interesting, at least; but splitting one, and making each new
transaction responsible for a sub-set of the actions of the original transaction, would just be a
pain to even request -- and should have been done in the first place by starting separate
transactions.)

As I've never played with a system that allowed this ... I may be imagining something I don't
actually want. It happens.

It would make it easier to take existing code performing actions and bind everything together; let
the existing code think it's committed, but let it do so in the context of a parent transaction you
control, with the possibility of undoing any part of the task (I'm writing a lot of Wizard screens
at the moment, which repeat the functionality of a lot of smaller but harder to use record screens -
- one advantage is that you can do any of the work in the wizard without committing, but doing any
of it with records means you've committed each little chunk of a greater task, and order may or may
not matter) ... That probably didn't make sense. Sorry.

The non-linearity would be a big implementation problem, I'd think. While the MGA can store the
back-versions appropriately, the inventory tables would have to handle more complex logic for
determining which other transactions a given transaction can see into. And the API for requesting
this could get nasty ... along with the over-the-write protocol (one transaction is currently
expected to do one thing at a time -- suddenly it'd be spawning multiple sub-transactions, all of
which could be simultaneously active.)

If I'm wrong about the linearity issue, then ... many many apologies?

-Philip

---------- Original Message -----------

> >Hmmm. All this talk of concurrent transactions, like looking at an open
> >bag of munchies, just
> >reminded me that I have a craving: fully nested transactions ... (feature
> >request)
>
> What semantics do you want for nested transactions? Firebird 1.5 has
> savepoints which give you the effect of nested transactions with these
> semantics:
>
> 0) Inner and outer transactions can see each other's work.
>
> 1) The outermost transaction can commit or rollback.
>
> 2) Inner transactions can only rollback.
>
> 3) When an inner transaction rolls back, its changes are undone, permanently.
>
> 4) When a transaction with inner transactions rolls back, all changes are
> undone, regardless of the state of transactions inside it.
>
> 5) When the outermost transaction commits, all changes made by inner
> transactions that have not rolled back are committed.
>
> 6) Inner and outer transactions can not deadlock against each other.
>
> Multiple transactions give you these semantics:
>
> 0) Multiple transactions from a single connection are independent.
>
> 1) They do not see each other's work.
>
> 2) They commit or rollback independently.
>
> 3) They can deadlock against each other.
>
> If you want to allow an inner transaction to commit, what happens an outer
> transaction rolls back? What does that do to transaction consistency?
>
> Regards,
>
> Ann
>
> Yahoo! Groups Links
>
>
>

------- End of Original Message -------