On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> >> From looking at how Oracle does them, autonomous transactions are
> >> completely independent of the transaction that originates them -- they
> >> take a new database snapshot. This means that uncommitted changes in the
> >> originating transaction are not visible to the autonomous transaction.
> > Oh! Recursion depth would need to be tested for as well. Nasty.
> Seems like the cloning-a-session idea would be a possible implementation
> path for these too.
Oracle has a feature where you can effectively save a session and return
to it. For example, if filling out a multi-page web form, you could save
state in the database between those calls. I'm assuming that they use
that capability for their autonomous transactions; save the current
session to the stack, clone it, run the autonomous transaction, then
restore the saved one.
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
In response to
pgsql-hackers by date
|Next:||From: Florian Weimer||Date: 2008-01-25 10:50:41|
|Subject: plperl: Documentation on BYTEA decoding is wrong|
|Previous:||From: Robert Treat||Date: 2008-01-24 22:37:04|
|Subject: Re: autonomous transactions|