Re: Pessimistic locking | Any feedback?

[Victor Langelo]

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".