On Sep 21, 2006, at 10:51 AM, Wolfgang Keller wrote: > > I was wrong here. PostgreSQL notifications don't require polling > the database > server. It's just the libpq client library itself that requires > polling a > function to retrieve the notifications. > > But an example for Psycopg2 shows how to solve this: "tap" the > socket where > the notifications arrive and poll the function only when something has > arrived.
if there is some psycopg2 method of receiving change notifications from the database, then it would not be too hard to write an extension to SessionContext that simply tracks all open sessions, receives the notifications, and sends appropriate expire() calls to the affected objects contained within those sessions. however this will mean that if you are in the process of doing some setting/ getting on one of those objects, your operation will need to be interrupted in some way, or some flag need be set so that the Session raises a concurrency exception when the flush() method is called. *or* - if you really really want all concurrent threads to totally share the same state at all times, you can have them all use the same Session, if you synchronize operations to that session since its not a threadsafe object by default. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
