On Wednesday February 20, 2002 01:48 am, Edmund Lian wrote: > Geoff wrote: > >>But it seems to me that in general, you'd have to lock the row for the > > entire duration of the servlet's processing. What if a user accesses a > servlet that takes 20 seconds to process, then in a different window or > frame tries to access a servlet that only takes 1/10 of a second to > process? > That first servlet will still be processing, and the second servlet will be > locked out for another 20 seconds. In other words, you'd have to serialize > the requests for a particular session, which is NOT the case if sessions > are > stored in memory.<< > > Aren't you still going to have a concurrent update problem if sessions are > stored in memory? You'll still need to use in-memory locks to serialize > access. > > Seems to me that unless the servlet is doing a heck of a lot, it should not > be locking a row for the duration of the operation, only just the critical > part, which you'd try to keep as fast as possible, and lock/unlock rows > immediately before and after the critical section. > > Now, if you use Oracle or PostgreSQL, then you wouldn't use locks at all, > but rely on MVCC to smooth things over (readers don't block writers and > vice-versa). If you truly do have concurrent writes to the same data, then > of course MVCC isn't going to help, only serialization of write access with > locks, which you can still do with Oracle/PostgrSQL.
Let me use an example that might help explain what I'm talking about. Suppose your session contains a value called "ServletHistory" which is simply a list that each servlet appends to. Using an in-memory store like SessionMemoryStore or SessionDynamicStore, there's no problem. In Python, appending to a list is atomic and thread-safe. You don't need to write any special locking code (in this case at least). Using SessionFileStore, you would get into trouble though. SessionFileStore loads in all session variables from disk at the beginning of the transaction and saves them all out at the end of the transaction. If 2 servlets are running simultaneously and both trying to append to the list, one servlet will overwrite the other and only one of the servlet's appends will make it into the list. So you'd have to add some sort of synchronization to deal with this properly (although I can't imagine how to fix it other than by serializing all servlets that use the session, since all session variables are stored in one big pickle file). 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. That's why I'm a proponent of keeping sessions in memory. - Geoff _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
