Re: Persistent data per connection
От | Steve Atkins |
---|---|
Тема | Re: Persistent data per connection |
Дата | |
Msg-id | 20050325174108.GA31237@gp.word-to-the-wise.com обсуждение исходный текст |
Ответ на | Re: Persistent data per connection (Jeff Amiel <jamiel@istreamimaging.com>) |
Ответы |
Re: Persistent data per connection
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: