Clustering with OJB
Return Receipt Your Clustering with OJB documen t: was Lasse Lambrecht/IS-LF1/Allianz-Leben receive d by: at: 16.08.2004 10:44:22
Howto: OJB 1.0.0 + Torque 3.1 + HSQLDB 1.7.2
Hi Guys,
For anyone interested, I've been able to get OJB 1.0.0, Torque-Gen 3.1
and HSQLDB 1.7.2 working together.
Torque 3.1 seems to work out of the box with OJB 1.0.0, but not with the
OJB JUnit tests because Torque 3.1 doesn't like the schema files used
for these tests. I've created some new schema files that seem to work OK
(linked to below).
HSQLDB 1.7.2 has problems with Torque because databases created using
HSQLDB's In-Process mode (as the standard DB is in the OJB JUnit
tests) must now be explicitly closed with a SHUTDOWN command for other
processes to use them. I've contacted the HSQLDB guys about a way to do
this using SQL, so that it could be included in Torque's template files,
but for now I've settled on patching the build-torque.xml file to do
this during the build process, if necessary.
HSQLDB 1.7.2 also has problems with one of OJB's testcases that uses
hardcoded SQL commands, specifically
org.apache.ojb.broker.sequence.NativeIdentifierTest as the syntax used
in this file is not allowed.
So, here are the steps to get Torque 3.1 working with OJB 1.0.0:
- Download OJB 1.0.0 from:
http://db.apache.org/builds/ojb/1.0.0/db-ojb-1.0.0-src.zip
and unpack the db-ojb-1.0.0 dir.
- Download torque-gen-3.1 from:
http://db.apache.org/builds/torque/release/3.1/torque-gen-3.1.zip
and unpack the torque-gen-3.1 dir.
- Remove old db-ojb-1.0.0/lib/torque-3.0.2.jar
- Copy torque-gen-3.1.jar and village-2.0-dev-20030825.jar from
torque-gen-3.1/lib/ to db-ojb-1.0.0/lib/
- Replace db-ojb-1.0.0/build-torque.xml with torque-gen-3.1/build-torque.xml
- Copy over
http://www.alphalink.com.au/~mwhart/ojb/ojbtest-data.dtd and
http://www.alphalink.com.au/~mwhart/ojb/ojbtest-data.xml
to db-ojb-1.0.0/src/schema/
- Grab copies of j2ee.jar and jdo.jar if you don't already have them and
copy them to db-ojb-1.0.0/lib/
- Make sure junit.jar is in $ANT_HOME/lib/ and then run ant junit from
the db-ojb-1.0.0 dir
(ignore the SQL error when trying to create the DB - you can get rid of
this by removing the ECHO Not implemented on the first line of
sql/db-init/hypersonic/createdb.vm in torque-gen-3.1.jar - and also
ignore the log4j ERROR messages - you can get rid of these by removing
the , org.apache.torque.engine at the end of line 15 of
log4j.properties in torque-gen-3.1.jar)
With any luck, all tests will pass!
Now, to get HSQLDB 1.7.2 working with OJB 1.0.0 (assuming previous steps
have been done):
- Download HSQLDB 1.7.2 from
http://prdownloads.sourceforge.net/hsqldb/hsqldb_1_7_2_3.zip?download
and unpack the hsqldb dir.
- Replace db-ojb-1.0.0/lib/hsqldb.jar with new hsqldb/lib/hsqldb.jar
- Replace
db-ojb-1.0.0/src/test/org/apache/ojb/broker/sequence/NativeIdentifierTest.java
with http://www.alphalink.com.au/~mwhart/ojb/NativeIdentifierTest.java
(diff below)
- If you want to support the new sequences in HSQLDB 1.7.2, replace
db-ojb-1.0.0/src/java/org/apache/ojb/broker/platforms/PlatformHsqldbImpl.java
with http://www.alphalink.com.au/~mwhart/ojb/PlatformHsqldbImpl.java
(diff below)
- Replace db-ojb-1.0.0/build-torque.xml with
http://www.alphalink.com.au/~mwhart/ojb/build-torque.xml (diff below)
- Run ant junit from the db-ojb-1.0.0 dir
Hopefully, all tests will pass again!
There are probably quite a few more changes introduced in HSQLDB 1.7.2
that could be updated in OJB, but sequences was all I was interested in
and they seem to work fine so far.
Cheers,
Michael
P.S.
Here are the diffs for those interested (sorry if it wraps):
diff for NativeIdentifierTest.java:
48c48
REF_ID int(11),NAME VARCHAR(250));
---
REF_ID INT, NAME VARCHAR(250));
58c58
NAME VARCHAR(250), FK_ID BIGINT, REF_ID int(11),
SINGLE_REF_FK BIGINT);
---
NAME VARCHAR(250), FK_ID BIGINT, REF_ID INT, SINGLE_REF_FK BIGINT);
diff for PlatformHsqldbImpl.java:
67a68,81
public String createSequenceQuery(String sequenceName)
{
return CREATE SEQUENCE + sequenceName;
}
public String nextSequenceQuery(String sequenceName)
{
return CALL NEXT VALUE FOR + sequenceName;
}
public String dropSequenceQuery(String sequenceName)
{
return DROP SEQUENCE + sequenceName;
}
$ diff for build-torque.xml (based on the file found in torque-gen-3.1,
not OJB):
249a250,318
!-- S H U T D O W N C H E C K
--
!--
--
!-- Hack to check if we need to shutdown the DB after we're done
--
!-- using it. At the moment, the only DB which this must be done
for --
!-- is HSQLDB when running in the In-Process mode.
--
!-- As this mode can be specified without a keyword, we just check
--
!-- that the JDBC URL (specified in the dbUrlToCheck property) is
--
!-- an HSQLDB URL, but not one of the other modes.
--
!--
--
target name=shutdown-check
condition property=torque.internal.shutdownAfterSql
RE: Jboss and ClassCastException (MetadataManager and JdbcConnectionDescriptor) -- anyone else have it?
Well, I believe I have found the crux of the issue.
I currently have two things deployed to my Jboss server, both which use
commons-lang (my non-OJB app is a Tapestry app, and is using langs1.0).
When my non-OJB app is deployed, I get the issue. However, when I
undeploy that app, and my OJB app is the only one deployed, and I can
redeploy as often as I would like.
So, obviously this is one of those infamous Jboss ClassLoader issues
(flat classloader space), and as such, I trying to figure out a
workaround. So, it seems like OJB really has no issue, but it was just
the brunt of the Jboss issues.
Thanks for all the help...and once I have found a working solution, I
will post it for all to see.
-Andrew
-Original Message-
From: Clute, Andrew [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 5:29 PM
To: OJB Users List
Subject: RE: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
I am wondering if it has something to do with the fact that
SerilizationUtils uses ObjectInputStream to serialize/desearlize the
objects, and ObjectInputStream on the deserialization does a
Class.forName() to create the new object -- which in the J2EE
classloader world can cause problems. I think that would explain why it
would use the previous versions. I am posting a message to the Jboss
group to see if my hypothesis is correct.
-Andrew
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Friday, August 13, 2004 5:25 PM
To: OJB Users List
Subject: Re: Jboss and ClassCastException (MetadataManager and
JdbcConnectionDescriptor) -- anyone else have it?
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization version after redploying, since
the url for that class is null. Not sure where it is loading it from,
or why it has a stored copy of it.
I must admit that I don't have a clue...
Did you checked commons-lang.jar? SerializationUtils is part of
commons-lang and if this jar wasn't redeployed it will use the 'old'
class-loader. Or is commons-lang duplicated in classpath?
regards,
Armin
Clute, Andrew wrote:
Well, I have narrowed the issue down further, but still do not have a
solution yet. In ConnectionRepository.getAllDescriptor(), the
JdbcConnectionDescriptor's that are in the current repository are
cloned
(seralized) into another list and returned. I made the guess (and I
was
right) that when this error is exposed, the JdbcConnectionDescriptor's
that are returned from the Serilization are loaded in a different
classloader than the ones that OJB creates!
To prove this, I changed the code for that method from:
[code]
public List getAllDescriptor()
{
return (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
}
[/code]
To:
[code]
public List getAllDescriptor()
{
Iterator it = jcdMap.values().iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + before Serialization:
+o.getClass().getClassLoader());
}
List returnList = (List) SerializationUtils.clone(new
ArrayList(jcdMap.values()));
it = returnList.iterator();
while (it.hasNext()){
Object o = it.next();
System.out.println(ClassLoader for +
o.getClass().getName() + after Serialization:
+o.getClass().getClassLoader());
}
return returnList;
}
[/code]
And as I assumed, the first time my application is deployed, the
classloader for the Connection is the same for both what OJB uses, and
what SerilizationUtils uses:
17:02:09,592 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
17:02:18,811 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56536OSNCore.ear
,addedOrder=37}
But, after redeploying it, the classloader for OJB changes (as I would
assume is correct), but the classloader for SerilizationUtils stays
the same as the previous version! Oops!
17:03:04,780 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor before
Serialization: [EMAIL PROTECTED]
url=file:/C:/jboss-3.2.5/server/default/tmp/deploy/tmp56537OSNCore.ear
,addedOrder=38}
17:03:11,280 INFO [STDOUT] ClassLoader for
org.apache.ojb.broker.metadata.JdbcConnectionDescriptor after
Serialization: [EMAIL PROTECTED]
url=null ,addedOrder=37}
So, now I need to figure out why this is happening. Something thing
looks weird for the after-serilization
can i use cloudscape?
Hi all, can i use cloudscape with OJB? regards saurabh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
object in QueryByCriteria
Dear Listmembers, I got the following problem: I try to retrieve an object via ojb using the PB API. The syntax looks like this: broker = PersistenceBrokerFactory.defaultPersistenceBroker(); QueryByCriteria query = new QueryByCriteria(oUser); result = (User) broker.getObjectByQuery(query); the oUser object has several attributes, like id, name, username, password ... Now somebody tries to login and the attributes username and password are set. That object ist then passed as criteria to QueryByCriteria. The weird thing is that the generated sql-statement looks like this: SELECT A0.username,A0.password,A0.id WHERE (((A0.id = 0) AND A0.username = 'userabc') AND A0.password = 'myPassword') My problem is A0.id = 0 ! And my question is, is there a way to tell ojb only to query the attributes that are set ? s.th. like: select A0.username,A0.password,A0.id where (( A0.username = 'abcUser') and A0.password = 'myPassword') Currently my version of ojb is 1.0rc6. Thanks in advance, Kind regards, Marc Tinnemeyer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: object in QueryByCriteria
My guess is your attributes have primitive types. That is, oUser.id has type int rather than Integer. If you use the later then just do not set the attribute that you do not want to use in criteria and since it will then be null, it won't be looked at. Ashish Marc Tinnemeyer wrote: Dear Listmembers, I got the following problem: I try to retrieve an object via ojb using the PB API. The syntax looks like this: broker = PersistenceBrokerFactory.defaultPersistenceBroker(); QueryByCriteria query = new QueryByCriteria(oUser); result = (User) broker.getObjectByQuery(query); the oUser object has several attributes, like id, name, username, password ... Now somebody tries to login and the attributes username and password are set. That object ist then passed as criteria to QueryByCriteria. The weird thing is that the generated sql-statement looks like this: SELECT A0.username,A0.password,A0.id WHERE (((A0.id = 0) AND A0.username = 'userabc') AND A0.password = 'myPassword') My problem is A0.id = 0 ! And my question is, is there a way to tell ojb only to query the attributes that are set ? s.th. like: select A0.username,A0.password,A0.id where (( A0.username = 'abcUser') and A0.password = 'myPassword') Currently my version of ojb is 1.0rc6. Thanks in advance, Kind regards, Marc Tinnemeyer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
