Re: autonomous transactions
| От | Hans-Juergen Schoenig |
|---|---|
| Тема | Re: autonomous transactions |
| Дата | |
| Msg-id | D81F36E4-65FB-4857-A6C6-543530948845@cybertec.at обсуждение исходный текст |
| Ответ на | Re: autonomous transactions (Decibel! <decibel@decibel.org>) |
| Список | pgsql-hackers |
On Jan 25, 2008, at 7:27 AM, Decibel! wrote:
On Wed, Jan 23, 2008 at 05:50:02PM -0500, Tom Lane wrote:Simon Riggs <simon@2ndquadrant.com> writes:From looking at how Oracle does them, autonomous transactions arecompletely independent of the transaction that originates them -- theytake a new database snapshot. This means that uncommitted changes in theoriginating 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 implementationpath for these too.Oracle has a feature where you can effectively save a session and returnto it. For example, if filling out a multi-page web form, you could savestate in the database between those calls. I'm assuming that they usethat capability for their autonomous transactions; save the currentsession to the stack, clone it, run the autonomous transaction, thenrestore the saved one.
If you want to use it for webforms you cannot just put it on the stack - you had to put it in shared memory because you don't know if you will ever get the same database connection back from the pool.
personally i like marko's idea. if a snapshot was identified by a key it would be perfect. we could present the snapshots saved as a nice nice superuser-readable system view (similar to what we do for 2PC)
the only thing i would do is to give those snapshots some sort of timeout (configurable). otherwise we will get countless VACUUM related reports.
this sounds like a very cool feature - definitely useful.
many thanks,
hans
--
Cybertec Schönig & Schönig GmbH
PostgreSQL Solutions and Support
Gröhrmühlgasse 26, 2700 Wiener Neustadt
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at
В списке pgsql-hackers по дате отправления: