From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | persistant transactions |
Date: | 2003-01-10 16:23:53 |
Message-ID: | Pine.LNX.4.33.0301100909580.2465-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I was wondering if it's feasible to have transactions that persist outside
of connections for certain purposes. I'm picturing something where
something like a web app could open a transacation and using transparent
sessions in php or something like that, it could open a multipage
transaction that could be accessed using non-persistant connections.
I could see this being a complete nightmare if the transactions didn't get
closed eventually, but with some kind of timeout setting this could be a
right useful feature.
But I'm not sure it belongs in the database proper. I'm thinking the way
to do something like this is to do it in plpgsql as a set of functions
that can initiate a pseudo transaction and a cron job that checks for
timeouts every x minutes and dumps the old transactions.
Does this idea make any sense at all? Is it a feature that would
make sense in the postgresql core code? Would it be something that would
be an absolute nightmare to actually code because of the connection
orientedness of the postgresql backend design and therefore should be
forever relegated to being done in a procedural language / cron job combo?
Scott Marlowe
From | Date | Subject | |
---|---|---|---|
Next Message | Iker Arizmendi | 2003-01-10 17:10:01 | rfc - libpq extensions |
Previous Message | Chantal Ackermann | 2003-01-10 15:49:03 | Re: unused tuples constantly increasing |