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.


Rich Armstrong
Genetics Software

----- Original Message -----
From: Victor Langelo
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 

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 

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

Reply via email to