geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Date Mon, 17 Jul 2006 20:50:34 GMT
+1 include them

On 7/17/06, Matt Hogstrom <matt@hogstrom.org> wrote:
> 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