gsstark@xxxxxxx wrote:
> I take it as a given that if suspended transactions were ever to
> appear people would expect a system table that let them list
> suspended transactions and how when they were suspended. Otherwise
> they just wouldn't be very manageable.
Regarding web applications, this turns out not to be too hard of a
problem to solve. Using the two options I identified: if you are able
to keep all your transaction data in the web server session, then this
data just disappears when the session goes away. No clean up necessary.
If you maintain state in a set of database tables, most implementations
assume that if the transaction ages past some threshold value (e.g., one
hour) without completion, the submitter decided not to complete. So you
just run a cron job once an hour that sweeps through these tables and
deletes anything older than the threshold. If you want to allow the
submitter to return at a later date and resume, then you are right, this
gets a little trickier, but not much. You still do the threshold
checking in case the submitter never returns, but you up the threshold
value to two weeks (or whatever.) And if the submitter does return, you
force him/her to resume or delete the existing transaction before they
can start a new one.
--
Guy Rouillier
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
