The BigDecimal problem is fixed. I submitted the patches a bit earlier. I
can now drive about 20% of the transations through the Web interface.working
through a load problem now.
----- Original Message -----
From: "David Jencks" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, June 08, 2005 10:01 AM
Subject: Re: [openejb-dev] FindByPrimaryKey executes two Queries
On Jun 7, 2005, at 10:58 PM, Matt Hogstrom wrote:
Thanks Gianny,
As soon as I complete the deploy of SPECj I'm happy to work on these
features. Both will have a dramatic impact on performance so crawling
through the code base now is preparing me for that next set of work.
Regarding the it turns out that I was incorrect, the problem was not the
Date field but was a java.math.BigDecimal field. The database column is
a DOUBLE and the Java type is java.math.BigDecimal. I worked with Jeremy
earlier today on this and am working out a patch. This brings up a
question. In TranQL is there a framework to provide database specific
mappings and transforms? For instance DB2 and Oracle both provide
support for converting a DOUBLE to long, int, short, byte, float,
java.math.BigDecimal, boolean or java.lang.String. I'm not sure about
Derby. The point is that there are extensions to common drivers that
provide additional conversion that simplifies life. From what I can see
TranQL may be artificially limiting by requiring more TypeConverters than
needed based on the JDBC driver that is being used.
After thinking about this overnight, isn't the solution to state in the
openejb plan that the column is Numeric? Then, even though it is actually
Decimal, tranql will use the get/set methods for Numeric<>BigDecimal and
force the driver to do the type conversions.
thanks
david jencks
Also, with regard to doing JOINS and providing support for SELECT FOR
UPDATE different databases have different issues. For instance, Oracle
allows a SELECT FOR UPDATE in a JOIN and DB2 does not. Although, DB2 has
specialized predicated that would allow for an UPDATE in a JOIN that
became available in DB2 8.2. I believe sybase does not support a SELECT
FOR UPDATE semantic but can use a null UPDATE command to obtain a
database lock. I guess my question is does TranQL allow for database
specific query and update generators to be plugged inthat will allow for
maximal SQL optimization ?
I'l let you know how my testing goes.
Cheers.
Matt
----- Original Message ----- From: "Gianny Damour"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, June 07, 2005 10:52 PM
Subject: Re: [openejb-dev] FindByPrimaryKey executes two Queries
Hello Matt,
I think that to do that for FindByPrimaryKey is rather simple. Yet, it
would be a non-optimal patch as it does not solve the problem as a
whole.
As a matter of fact, I have started to work on CMP and CMR prefetching
(see http://issues.apache.org/jira/browse/GERONIMO-665 for more
details). Based on my current estimates, you should expect something
working by end of next week.
Meanwhile, if you want to give us a hand with respect to database
operations, here are two things that I think we want to have:
* batch updates: I think that this is an easy one and a good way to get
started with TranQL; and
* cache across transactions: I think that it is much more complex.
Please note that I am happy to provide my support if you want to work on
any of these two items.
BTW, have you been able to identify the problem associated to the
java.sql.Date field?
Thanks,
Gianny
On 8/06/2005 12:36 PM, Matt Hogstrom wrote:
I've been testing FBK and found that there are two queiries being
executed. First a SELECT is done against the PK for the bean and that
is followed by a SELECT for the columns of the bean. Performance can
be improved by executing the second query only and getting the PK and
all the coluns in one shot. Can we make the defulat for FBK and EJBQL
queries to get all the data straight away as the default.
Is this a simple change?
