While I appreciate (and I am sure others do) Jonathan's lucid explanation of the problem, I am not sure there is a good solution. As he noted there is an inherent tradeoff between isolation level and availability. Running the database at a serializable isolation level is not acceptable in many cases. Optimistic locking is an alternative but it isn't trouble free either because you're going to fail one of the transactions at commit time if they conflict. Which means somewhere in your application you're going to have to have retry or failure handling, which can be complex. Someone who goes on an hour long shopping spree on your web site and fills up their cart had better be able to recover if they have a problem at checkout. Plus optimistic locking is hard to implement portably because of database variations. Oracle has a timestamp type but this isn't portable. Some databases have auto-increment columns which can be very handy for implementing this but others don't or the semantics or the SQL differ. There are acceptable solutions in this area but I don't know of any that both provide transparency (i.e. from the standpoint of the application programmer, it just works) and don't impact performance. --Jon ---------------------------------------------------------- Jon Dart [EMAIL PROTECTED] TIBCO Software Inc. 650-846-5099 =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
