geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Date Mon, 17 Jul 2006 21:25:57 GMT
I think the first two are definitely bugs. You lost me on the  
discussion of 2128...

I'd like to see the discussion included on OpenEJB dev, also...

--kevan

On Jul 17, 2006, at 4:47 PM, 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.
>
> Matt


Mime
View raw message