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? (ii) Which are the places where you would clear the transaction? I am already doing at save(), cancel() and ejbRemove() methods. (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. Rich Armstrong Genetics Software http://www.kromosoft.com =========================================================================== 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".
