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. ...Edmund. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
