From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, 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:58:43 |
Message-ID: | 871x1huoa4.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:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> >> 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.
>
> [ itch... ] This seems to me to fly right in the face of the
> oft-repeated advice that you don't hold a transaction open while the
> user thinks about it, goes off to lunch, vacations in the Bahamas, etc.
Sure, I said that was the answer people get when they ask about this. And it's
clearly better approach if it's available. But what if the locking or MVCC
semantcis *are* what you need?
If you really do need to allow one user to edit the information and still
present the existing information to others but not let them update it
concurrently, etc. Reimplementing full ACID semantics is hard and easy to get
wrong. We already have a tool that provides them properly.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | HS | 2005-11-16 06:09:50 | installation(pg_depend) problem |
Previous Message | Tom Lane | 2005-11-16 05:34:58 | Re: PREPARE TRANSACTION and webapps |