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