Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?

[Aaron Mulder <am...@alumni.princeton.edu>]

+1 include them

On 7/17/06, Matt Hogstrom <ma...@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
>