On Wednesday February 20, 2002 10:24 pm, Edmund Lian wrote: > 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. >
My worry is that you'll end up with something like ZODB with ZEO if you want a SQL session store to be flexible enough to store any Python object that can be pickled (like the current SessionStores) but avoid concurrency problems. That's a complicated system. (Not to mention the fact that ZODB/ZEO forces you to program in a non-intuitive manner because of its use of optimistic locking.) If you don't need a fully general session storage, you can certainly roll your own specialized SQL session store for more limited types of data without too much trouble -- but it probably won't be as flexible as the one that comes with Webware, and it might be harder to use. (I'm speculating here.) - Geoff _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
