On Fri, Mar 25, 2005 at 10:56:50AM -0600, Jeff Amiel wrote: > because the connection is never really dropped... > using a connection pool....so it's just reclaimed by the pool on a > connection.close() or after a timeout period
Then you don't really want per-connection state, you want per-client-session state. Presumably you're generating a unique identifier for each client session somewhere in the client app? You could use that unique identifier to store whatever information you need for that session in a table. This sounds like a pretty normal "keep state based on a cookie" problem, as solved by a bunch of web apps. If you're looking for higher performance you might want to look at memcached and the postgresql interface to it (pgmemcache?). > Tom Lane wrote: > > >Jeff Amiel <[EMAIL PROTECTED]> writes: > > > > > >>We've been struggling for several days now to come up with a mechanism > >>that allows us to establish a mechanism to store data that remains > >>persistent for the life of the connection. > >> > >> > > > >Why don't you just store it in a temporary table? Goes away at > >connection drop by definition ... and each connection can use the same > >name for the temp table, so coding is easy. > > > > regards, tom lane > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
