You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Matt Hogstrom <ma...@hogstrom.org> on 2006/07/17 22:47:11 UTC
OpenEJB JIRAs for 1.1.1 - bugs or features ?
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
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Posted by John Sisson <jr...@gmail.com>.
+1 to all of these if you have the time to get them into 1.1.1. Even
though some can be considered features they are really resolving
usability issues. After all, there is no point having a server that is
compliant but not usable in the real world.
Thanks,
John
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
>
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Posted by Kevan Miller <ke...@gmail.com>.
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
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
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
Re: OpenEJB JIRAs for 1.1.1 - bugs or features ?
Posted by 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
>