Thanks Victor, Thanks for a comprehensive response. Since the posting, we had gone ahead and implemented the system as described below. Some of the pitfalls that you mention below, we had foreseen and designed, and some we hadnt, so we will enhance the system now.
One simple mechanism that we are using to do cleanup (though not comprehensive) is the HttpSessionBindingListener. Regarding performance comparison, we will do benchmarking and also make the results available. I am sure that others have done that in the past, and I am curious to see those past results. So, if anyone knows of performance comparison between pessimistic and optimistic locking, please let me know. thanks, Rich Armstrong Genetics Software http://www.kromosoft.com ----- Original Message ----- From: Victor Langelo To: EJB-INTEREST@JAVA.SUN.COM Sent: Thursday, April 07, 2005 8:52 PM Subject: Re: Pessimistic locking | Any feedback? Rich Armstrong wrote: I just wrote an application that allows a user to edit orders (and the sub objects). I am using pessimistic locking, and the rough architecture is as follows: OrderSFS is the stateful session bean for the orders entity. One method of this opens a transaction, isolation level set to REPEATABLE READ. Another method commits the transaction. The reason I am using pessimistic locking (and not optimistic locking) is because user does not want to lose any changes made to orders (as a mid air collision), but it is acceptable to lock users out of orders (if they are being edited by someone else). Few questions regarding this: (i) Has anyone used this method, and if so, are there any traps/pitfalls to avoid? Yes we have in a simple client server architecture. It's OK if there are only a few users and they're in the same room. You realize you're depending on the user to always cancel or save an edit? Users are human not computers and you'll have to handle every possible outcome. For instance they're computer will crash while using another application. They'll put they're machine to sleep and disconnect it from the office network. It all happens. (ii) Which are the places where you would clear the transaction? I am already doing at save(), cancel() and ejbRemove() methods. The following section of the spec will cause you problems because there will be transactions that never commit or rollback. 7.6.3 Missed ejbRemove Calls The Bean Provider cannot assume that the container will always invoke the ejbRemove method on a session bean instance. The following scenarios result in ejbRemove not being called on an instance: • A crash of the EJB container. • A system exception thrown from the instance’s method to the container. • A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB container implementation-specific way. If the session bean instance allocates resources in the ejbCreate<METHOD> method and/or in the business methods, and normally releases the resources in the ejbRemove method, these resources will not be automatically released in the above scenarios. The application using the session bean should provide some clean up mechanism to periodically clean up the unreleased resources. For example, if a shopping cart component is implemented as a session bean, and the session bean stores the shopping cart content in a database, the application should provide a program that runs periodically and removes “abandoned” shopping carts from the database. (iii) We realize that the performance is going to be worse than optimistic transactions (setting transactions to READ_COMMITTED, and only the changes of first person who saves go through). But we dont know by how much. If you wish to answer this part, please be specific, but please no buzz words on this issue. We cannot tell you by how much either. It depends on contention for resources. You'll need to do some benchmarks on your app. --Victor Langelo Eclipse Services =========================================================================== 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".
