Re: Nested Transactions, Abort All - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Nested Transactions, Abort All
Date
Msg-id 20040702193808.GA27358@dcc.uchile.cl
Whole thread Raw
In response to Re: Nested Transactions, Abort All  (Thomas Swan <tswan@idigx.com>)
Responses Re: Nested Transactions, Abort All
List pgsql-hackers
On Fri, Jul 02, 2004 at 01:37:46PM -0500, Thomas Swan wrote:
> Alvaro Herrera wrote:

> >>Then again, since a statement is always transactionally wrapped, would
> >>it be required to always issue SUBBEGIN if issued from within a
> >>function?  This would address my concern.
>
> Isn't this counterintuitive.   It seems that BEGIN and COMMIT/ABORT 
> should be sufficient regardless of the level.  If you are inside a 
> current transaction those commands start a new transaction inside of the 
> current transaction level, just like pushing on and popping off elements 
> on a stack.  

No, the first level is quite different from any other, and that's why it
should use a different syntax.  Really any level above level 1 is not a
transaction at all; it's a unit that you can rollback independently but
nothing more; you can't commit it independently.  I think a better term
than "subtransaction" or "nested transaction" is "rollback unit" or some
such.

> Some functions and procedures may not be called inside of transactions  
> or subtransactions.

No.  Some functions cannot be called inside a transaction block.
Whether you are or not inside a subtransaction within the transaction
block is not important.  In fact, the application doesn't care what
nesting level it is in; the only thing that it cares about is if it is
in a transaction block or not.

Please note that I'm using the term "transaction block" and not
"transaction."  The distinction is important because everything is
always inside a transaction, though it may be an implicit one.  A
transaction block, on the other hand, is always an explicit thing.
And a subtransaction is also an explicit thing.


> Unless you have some way to tell (by query) the state you are in is a 
> subtransaction and how many levels you are deep into the nested 
> transaction, deciding whether to use SUBBEGIN and SUBCOMMIT/SUBABORT vs 
> the traditional BEGIN COMMIT/ABORT becomes nondeterministic.

The application always has to keep track if it is inside a transaction
block or not.  This has always been true and it continues to be so.
Whether you are inside a subtransaction or not is not really important.
If you want to commit the whole transaction block just issue COMMIT, and
all levels will be committed.  Similarly if you want to abort.  But if
you want to retry a subtransaction which has just failed you better know
whether you are on a subtransaction or not ... I mean if the app
doesn't know that then it isn't using subtransactions, is it?

Knowing just the nesting level will not help you -- the app has to know
_what_ to retry.  And if it isn't going to retry anything then there's
no point in using subtransactions at all.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Cuando mañana llegue pelearemos segun lo que mañana exija" (Mowgli)



pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: Nested Transactions, Abort All
Next
From: Thomas Swan
Date:
Subject: Re: Nested Transactions, Abort All