Skip site navigation (1) Skip section navigation (2)

Re: autonomous transactions

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Neil Conway <neilc(at)samurai(dot)com>,Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>,Alvaro Herrera <alvherre(at)commandprompt(dot)com>,"Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>,"pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: autonomous transactions
Date: 2008-01-25 06:27:40
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
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! Team #1828

In response to


pgsql-hackers by date

Next:From: Florian WeimerDate: 2008-01-25 10:50:41
Subject: plperl: Documentation on BYTEA decoding is wrong
Previous:From: Robert TreatDate: 2008-01-24 22:37:04
Subject: Re: autonomous transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group