At 07:05 AM 5/27/2004, unordained wrote:

>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