From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Jens Lechtenboerger <lechten(at)wi(dot)uni-muenster(dot)de> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-interfaces(at)postgresql(dot)org |
Subject: | Re: Lost updates vs resumable connections/transactions |
Date: | 2004-12-16 18:05:22 |
Message-ID: | 876532p199.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Jens Lechtenboerger <lechten(at)wi(dot)uni-muenster(dot)de> writes:
> But why should I have SQLRelay between me and the database?
> I don't plan to use any of its "real" features. It would just be a
> proxy with a known address that maintains a database connection.
> Obviously, the database server itself has a known address and
> maintains database connections...
The problem is that a database session keeps more state than just a
transaction id. It also keeps locks and other resources that would need to be
put aside in RAM. And for something like Apache where the new request could be
coming in to a different backend, these resources would have to be migrated to
the new backend when the session is resumed.
It could be done, but the most direct way to do it would be to keep around the
entire backend using something like SQLRelay. The resources used by SQLRelay
itself aren't really the concern here. They're dwarfed by the resources pinned
down by the database backends being kept around waiting in case the
application user comes back.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2004-12-16 18:05:46 | Re: Lost updates vs resumable connections/transactions |
Previous Message | Jens Lechtenboerger | 2004-12-16 13:52:49 | Re: Lost updates vs resumable connections/transactions |