geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject OpenEJB JIRAs for 1.1.1 - bugs or features ?
Date Mon, 17 Jul 2006 20:47:11 GMT
I opened 3 JIRAs that affect CMP deployment, Session bean performance and consistency.

The JIRA's in question are:

GERONIMO-2127 - Expose ability to use SELECT FOR UPDATE
GERONIMO-2129 - Allow user to specify pool size on Stateless Session Beans
GERONIMO-2128 - Allow user to specify an Isolation Level on a CMP Bean

I think  these items can be argued in two ways.  Bugs and features.

Based on my experience with CMP beans what we have for Geronimo is fully compliant with the
J2EE 
specification.  We pass the tests and are compliant.

However, our current implementation does not allow for a user to deploy an application that
will 
ensure data consistency.  For instance, if one is using Oracle as the database, which operates
at 
Read Committed by default, two competing applications will possible overlay data from one
another 
with no notification at all.  In order to properly provide for ACID properties a SELECT FOR
UPDATE 
needs to be provided so one application can block another.  I consider this a bug since even
though 
the implementation "is compliant" it is also unusable unless your data is read-only or you
can 
guarantee no conflicts in some other way.

The second issue goes to consumability as well as accuracy.  Stateless session beans are 
traditionally used as facades and wrappers for Tx.  They are also used to store information
that is 
transient but expected to be longer lived than a single use.  The SLSB in OpenEJB has a pool
size of 
one and will make some applications perform poorly and perhaps malfunction.

In the case of SPECjAppServer it will do both.  The SLSB is used in that application as a
temporary 
cache for keys used to insert into a database.  The current behaviour is that on every request
a new 
block of keys is retrieved from the Key database.  For SPECj and DayTrader it results in deadlocks

and collided keys.  The Pool (which does exist but is fixed at a size of 1) will eliminate
this problem.

2128 is similar to 2127 in so far as using database isolation to provide ACID properties it
allows 
for multiple Isolation levels to be used such that RDBMs such as DB2 or Derby can perform
better. 
Although this isn't required for ACID properties it does require a schema change to OEJB 2.1.1.

All of these JIRA's can be implemented without disrupting current applications so I believe
we 
should include them in 1.1.1.

The changes are actually limited to OEJB and TranQL which are components of G.

My vote is to include these JIRA's.

Matt

Mime
View raw message