Re: Session based transaction!! - Mailing list pgsql-general

From John R Pierce
Subject Re: Session based transaction!!
Date
Msg-id 4B34E0BB.7000703@hogranch.com
Whole thread Raw
In response to Session based transaction!!  (S Arvind <arvindwill@gmail.com>)
List pgsql-general
S Arvind wrote:
> Hi Everyone,
>
> In a web application running in Tomcat and Postgres 8.3 as DB, i need
> to know whether my given task is feasible or not.
>            All the db operation which is done by that web application
> must be rollback at the end(session dies) and the DB data must be same
> as the starting stage(of session). Its like virtually placing the data
> for that session alone and rollbacking the db to the template which is
> originally been. So whenever users get in the webapplication, the
> initial data must be the template data only and he can perform any
> operation for which data is visible for that user alone and when the
> users leaves(session destroyed) all the data changed in that time must
> be rollbacked.
>
> I thought this by, When the session created in the application a
> transaction must be started and all the activites must be done on the
> DB, but the transaction will not be commited or rollback across
> request but it must be done across the session. By not destroying the
> connection and using it for all the work done by that session. when
> session destroy we can rollback the entire transaction

when exactly might the session be destroyed if, for instance, the user
wanders off bored or abruptly closes his browser ?   http sessions are
independent of http sockets, at least in http/1.1

eventually, presumably, you time out the idle session, bit isn't that
typically in several hours?

transactions that run many hours are painful for postgres, they intefere
with vacuum processing, and can lead to bloated tables, especially on
databases that ahve high transactional rates.

you likely will need to manage your own database connections, and keep
them with your session tracking data.  you may need to implement your
own specialized version of a connection pool, this one would return a
specific session upon request rather than the next available one, and be
closely tied into your session manager.

pgsql-general by date:

Previous
From: Greg Stark
Date:
Subject: Re: date_trunc on date is immutable?
Next
From: John R Pierce
Date:
Subject: Re: Out of space making backup