From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Cc: | Jens Lechtenbörger <lechtej(at)uni-muenster(dot)de>, pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Lost updates vs resumable connections/transactions |
Date: | 2004-12-15 19:43:41 |
Message-ID: | 87is73qrde.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Even applications that have statefull enduser terminals (like SAP R/3 for
> example) never allow an open transaction over user interaction.
I'm not sure using SAP as your paragon of design excellence is a wise choice
here. From what I understand SAP implemented its own locking system because
the database it was based on didn't offer any locking at all.
But your basic point is sound. For a web site I would definitely avoid using
anything like database locks and even avoid doing anything with application
locks if possible.
If you really really want to expose the database session state I think he's on
the right track using SQLRelay. This would let him handle reconnecting a user
with her session even if she's connecting to a different Apache process.
I suspect the database wouldn't really be able to suspend a database
connection using any less memory than just keeping the entire backend process
with its session around anyways.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Jens Lechtenboerger | 2004-12-15 19:57:48 | Re: Lost updates vs resumable connections/transactions |
Previous Message | Dave Cramer | 2004-12-15 17:06:46 | Re: postgresql-7.4.5 |