Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Q7r0wI016PfWj4brkXXWt4AdsOowpD+2cQiugt4hpdUbO0P2nWn7lwKOK+kwJfQMFoJfkRBEvek/GuWMliPUqB9ebHd0dH12zGqB2K0pyuCbhDK2YC2j6w79VVleO0QnwBbU+dTjRFJ3Km1kc68fJYgbSYVLjGABDqm79k3CEAw=
Message-ID: <74e15baa0607171350r4b2d4bd7gcc6a10a258f76259@mail.gmail.com>
Date: Mon, 17 Jul 2006 16:50:34 -0400
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org
Subject: Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
In-Reply-To: <44BBF74F.2060302@hogstrom.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44BBF74F.2060302@hogstrom.org>

+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
>