Re: PREPARE TRANSACTION and webapps

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: PREPARE TRANSACTION and webapps
Date: 2005-11-16 05:19:46
Message-ID: 877jb9uq31.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> writes:
> > Can we have a reconnect and "reopen prepared/saved transactions" feature?
> > Please? :)
>
> What this would actually be useful for is a fair question
> though --- what's it do that you don't have now?

I think what they want to do is make the database concept of transactions
match up 1-1 with their application's concept of transactions. Which may span
multiple stateless http requests.

That usually means reengineering the http server and driver layers to keep
backends around and pull out the right one for every http request. But doing
that involves keeping around entire backends, which isn't terribly efficient
with kernel resources. It also involves adding some connection pool
infrastructure which are always annoying. At every level it imposes lots of
constraints on the application design.

The alternative is to reimplement some limited locking at the application
layer or finessing the situation somehow. That's what's usually recommended
here and it's what I usually do. But if what you really need is full ACID
semantics presented to the user then reimplementing the entire MVCC system
seems unnecessary when it all already exists in the database.

--
greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-11-16 05:34:58 Re: PREPARE TRANSACTION and webapps
Previous Message Tom Lane 2005-11-16 04:27:25 Re: PREPARE TRANSACTION and webapps