Geoff,
>>A SQL SessionStore would also need the same sort of locking, but maybe it could be smarter since it doesn't necessarily have to store all values in one big pickle. But still, that means that servlet code can no longer simply access sessions as though they are a simple Python dictionary in memory, but you now have to deal with synchronization issues, making your servlet code more complicated.<< Interesting example. In this specific example, could you not just solve the problem by using a SQL SessionStore that contains one row for each history entry? If the history list gets long, then you have a different problem (a potentially huge table), but this solution means that two or more servlets can do concurrent inserts since they're writing to different rows. You can always write a wrapper to make the SQL SessionStore behave like a (slower) dictionary. This is in fact what I did to implement my own SQL SessionStore. The major advantage of using a RDBMS based session store is that it's possible to fail-over from one webserver/appserver set to another. I'd rather spend tons of money on a single high-availability DB server and use many el-cheapo web/app servers than spend the same amount of $$ on more reliable but more expensive web/app servers. ...Edmund. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
