Re: Lost updates vs resumable connections/transactions

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

In response to

Browse pgsql-interfaces by date

  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