geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Date Mon, 17 Jul 2006 21:37:01 GMT
Matt Hogstrom 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.

Include them if you can get them done in time.


Regards,
Alan




Mime
View raw message