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 <jamiel@istreamimaging.com> 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 majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
