RE: Optimistic Locking using the PersistenceBroker API
Yes, we use it. It is really easy. You need a field in each table which is either integer or timestamp. I use integer. And then you need to identify this in your repository_user.xml. The entry looks like this : field-descriptor id=1 name=rowVersion column=rowVersion jdbc-type=INTEGER locking=true / I believe that's all. If you get a violation, an OptimisticLockException is thrown. Bonnie MacKellar -Original Message- From: Andy Czerwonka To: OJB Users List Sent: 10/28/03 2:43 PM Subject: Optimistic Locking using the PersistenceBroker API Has anyone implemented an optimistic-locking strategy (I actually may need a Pessimistic strategy - not sure yet) using the PersistenceBroker API? Can you point me in the right direction? -andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: problems with batch-mode=true
Hi,
Yes, I had tracked it down to this code segment yesterday, but
wasn't sure how to proceed.
thanks,
Bonnie MacKellar
-Original Message-
From: Mark Rowell
To: 'OJB Users List'
Sent: 10/23/03 5:23 AM
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is concerned)
that in the doExecute method
of PreparedStatementInvocationHandler.java the following line (223) gets
invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I get
a
similar error to
Bonnie (java.lang.IllegalArgumentException: object is not an instance of
declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.Pr
epar
edStatement)
And we are trying to executed it on the statement rather than passing
the
platform instance. I think the problem
Is in the if statement in that it does an == rather than a .equals()
call to
determine whether we
want to call the addBatch method. Now, I do not know whether within a
single
JVM that the following
Returns true
Method method1 = obj.getClass().getMethod(methodName, args);
Method method2 = obj.getClass().getMethod(methodName, args);
method1 == method2; // is this gurantee dto be true like it is for
instances
of Class e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode=true
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of
declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doEx
ecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invo
ke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unkn
own
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
wn
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMi
grat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called:
[EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException:
ConnectionManager
is NOT in transaction
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknow
n
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(
Unkn
own Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(
Unkn
own Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMi
grat
ion.java:75)
Exception in thread main
It looks like the persistence broker is being closed down before the
call to
abortTransaction
is made. But that does not explain the first exception. This code works
perfectly with
batch-mode=false.
And, if I call executeBatch, I don't get the second exception (the one
about
not being in
a transaction), although I still get the first transaction.
I am including my repository_database.xml as an attachment
RE: problems with batch-mode=true
I have the same problem! I thought I was
the only one.
Bonnie MacKellar
-Original Message-
From: Mark Rowell
To: 'OJB Users List'
Sent: 10/23/03 7:59 AM
Subject: RE: problems with batch-mode=true
Armin
No because I am not allowed to use CVS where I work..hence...
Oh well!
Thanks
Mark
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 11:37
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi Mark,
did you tried latest version from CVS?
I think your mentioned bug was fixed in
CVS.
See
http://cvs.apache.org/viewcvs.cgi/db-ojb/src/java/org/apache/ojb/broker/
util
/batch/PreparedStatementInvocationHandler.java
regards,
Armin
Mark Rowell wrote:
Hi
As a follow on I checked the source for java.lang.reflect.Method and
it has an implementation Of equals which could possibly indicate tat
the equality operator (==) does not hold for methods.
Mark
-Original Message-
From: Mark Rowell [mailto:[EMAIL PROTECTED]
Sent: 23 October 2003 10:23
To: 'OJB Users List'
Subject: RE: problems with batch-mode=true
Hi
Regarding this issue it looks like (at least as far as RC4 is
concerned) that in the doExecute method of
PreparedStatementInvocationHandler.java the following line (223) gets
invoked
((Method) _methods.get(i)).invoke(stmt, (Object[]) _params.get(i));
In my case when using batched mode, and JSQLConnect on MSSqlServer I
get a similar error to Bonnie (java.lang.IllegalArgumentException:
object is not an instance of declaring class)
The methods returned by _methods.get(i) is
public void
org.apache.ojb.broker.platforms.PlatformDefaultImpl.addBatch(java.sql.
Prepar
edStatement)
And we are trying to executed it on the statement rather than passing
the platform instance. I think the problem Is in the if statement in
that it does an == rather than a .equals() call to determine whether
we want to call the addBatch method. Now, I do not know whether within
a single JVM that the following Returns true
Method method1 = obj.getClass().getMethod(methodName, args);
Method method2 = obj.getClass().getMethod(methodName, args);
method1 == method2; // is this gurantee dto be true like it is for
instances of Class e.g.
Obj.getClass() == Obj.getClass() is guranteed to be true?
Regards,
Mark Rowell
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: 22 October 2003 14:02
To: OJB Users List
Subject: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode=true
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of
declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doEx
ecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invo
ke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unkn
own
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
wn
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
nown Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(Unk
nown Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMi
grat
ion.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not
an
instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close
RE: problems with batch-mode=true
Title: RE: problems with batch-mode=true
Hi,
Here is the code that I tested. You can
see that setBatchMode is called before I start
the tx.
try
{
broker.serviceConnectionManager().setBatchMode(true);
broker.beginTransaction();
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
// conMan.executeBatch();
broker.commitTransaction();
}
catch(Exception e)
{
e.printStackTrace();
logger.error(e.getMessage());
broker.abortTransaction();
}
finally
{
broker.close();
}
This chunk of code, exectued with batch-mode=true
in repository_database.xml, results in the following
two exceptions :
java.lang.IllegalArgumentException: object is not an instance of declaring class
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecute(Unknown Source)
at org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(Unknown Source)
at $Proxy0.doExecute(Unknown Source)
at org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown Source)
at org.apache.ojb.broker.util.batch.BatchConnection.commit(Unknown Source)
at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localCommit(Unknown Source)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unknown Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unknown Source)
at com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigration.java:69)
3425 ERROR [main] dbmigrationutils.CustomerMigration - object is not an instance of declaring class
3435 DEBUG [main] core.PersistenceBrokerImpl - PB.close was called: [EMAIL PROTECTED]
org.apache.ojb.broker.TransactionNotInProgressException: ConnectionManager is NOT in transaction
at org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unknown Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unknown Source)
at com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigration.java:75)
Exception in thread main
It looks like the persistence broker is being closed down before the call to abortTransaction
is made. But that does not explain the first exception. This code works perfectly with
batch-mode=false.
And, if I call executeBatch, I don't get the second exception (the one about not being in
a transaction), although I still get the first transaction.
I am including my repository_database.xml as an attachment. It is always possible that
I am doing something terribly wrong there. The relevant jcd-alias is ActiveBillStandalone
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 21, 2003 5:37 PM
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi,
hmm, this should not happen.
Please try to set
broker.serviceConnectionManager.setBachMode(true);
before start the tx. Because the connection was
associated with PB instance on PB.beginTx, so setting
batch-mode after this may cause problems.
I currently made some tests against sapDB
without any problems (using CVS head)
regards,
Armin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : problems with batch-mode=true
If I am understanding it correctly, it is supposed to be
a way to interface with the underlying batch mode in JDBC.
There, you add insert statements to a batch, and then
execute them all at once. It should save on overhead.
We have to migrate a large customer database, so we
need any overhead savings we can get.
Please, anyone who knows more than me about this, correct
me if I am wrong!
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Emmanuel Dupont [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 22, 2003 2:34 AM
To: 'OJB Users List'; [EMAIL PROTECTED]
Subject: RE : problems with batch-mode=true
I read inb the doc but I didn't understood what the batch
mode=true means.
Can someone explain it to me ?
Tx !
-Message d'origine-
De : Armin Waibel [mailto:[EMAIL PROTECTED]
Envoyé : mardi 21 octobre 2003 22:58
À : OJB Users List
Objet : Re: problems with batch-mode=true
Hi Bonnie,
Hope I can sheed some light on the 'problem'.
does this mean that you can't set batch mode to true
if it is set to false in repository_database.xml?
yep!
I think this behaviour has a big advantage, because it is
easy to disable batch-mode by set batch-mode false in
repository (if we don't have a bug in handling bach-mode ;-))
...
I am trying to insert records in batch mode. Perhaps I
don't understand
how this
works. Here is my test code to insert 100 customers :
Assume you have set batch-mode 'true' in repository
file. Then you have to enable batch mode for the use
PB instance.
Try this:
ConnectionManagerIF conMan =
broker.serviceConnectionManager();
try
{
broker.beginTransaction();
== broker.connectionManager.setBachMode(true);
now the PB instance is running in batch-mode till you set
false or the PB instance was closed.
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
conMan.executeBatch();
think you don't need executeBatch before commit, this will be done
at commit.
broker.commitTransaction();
}
If you still have problems with batch-mode try CVS-head. I think
Oleg has checked in some changes (but I'm not sure)
regards,
Armin
When I run this with batch-mode=false, it works
perfectly, although it
generates a SELECT and a
DELETE for every INSERT (which seems rather inefficient).
I imagine this
has something to do with
an M:N nondecomposed relationship which involves Customer records.
When I run this with batch-mode=true, it fails. I get
the following
exception
java.lang.IllegalArgumentException: object is not an instance of
declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHa
ndler.doExec
ute(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHa
ndler.invoke
(Unknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.execut
eBatch(Unkno
wn Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(
CustomerMigr
ation.java:68)
rethrown as
org.apache.ojb.broker.accesslayer.OJBBatchUpdateException:
object is not an instance of declaring class
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.execut
eBatch(Unkno
wn Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(
CustomerMigr
ation.java:68)
when conMan.executeBatch() is called.
Am I doing something wrong here? I am using rc4, with
MSSqlServer and
JSQLConnect.
thanks,
Bonnie MacKellar
-
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]
does runtime setBatchMode work?
I am using rc4, with MSSqlServer. I posted Friday with a problem
while running in batch mode. I still haven't resolved it, and it is a major
problem for us. I am hoping someone reads my email and has
an idea.
While searching through the OJB source to find the cause of my
error, I also found this in ConnectionManagerImpl#setBatchMode :
public void setBatchMode(boolean mode)
{
/*
arminw:
if batch mode was set 'false' in repository,
never enable it.
There are many users having weird problems
when batch mode was enabled behind the scenes
*/
batchMode = mode jcd.getBatchMode();
}
Does this mean that you can't set batch mode to true
if it is set to false in repository_database.xml?
This is certainly the behavior I have seen - only changing the
setting in the repository has an effect, and changing it
at runtime has no effect. Could someone tell me if this
is true or not?
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
FW: problems with batch-mode=true
Here is a repost of my original problem with batch mode, just in case
someone sees it and has a good idea. I don't know if I am just coding
this wrong, or if there is a more serious problem. This is a major problem
since we need to migrate a lot of records into a database, and would
like to do it in batch mode.
thanks
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Bonnie MacKellar
Sent: Monday, October 20, 2003 11:42 AM
To: OJB Users List (E-mail)
Subject: problems with batch-mode=true
I am trying to insert records in batch mode. Perhaps I don't understand
how this
works. Here is my test code to insert 100 customers :
ConnectionManagerIF conMan = broker.serviceConnectionManager();
try
{
broker.beginTransaction();
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
conMan.executeBatch();
broker.commitTransaction();
}
When I run this with batch-mode=false, it works perfectly, although it
generates a SELECT and a
DELETE for every INSERT (which seems rather inefficient). I imagine this
has something to do with
an M:N nondecomposed relationship which involves Customer records.
When I run this with batch-mode=true, it fails. I get the following
exception
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExec
ute(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke
(Unknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.executeBatch(Unkno
wn Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigr
ation.java:68)
rethrown as org.apache.ojb.broker.accesslayer.OJBBatchUpdateException:
object is not an instance of declaring class
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.executeBatch(Unkno
wn Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigr
ation.java:68)
when conMan.executeBatch() is called.
Am I doing something wrong here? I am using rc4, with MSSqlServer and
JSQLConnect.
thanks,
Bonnie MacKellar
RE: problems with batch-mode=true
I tried your suggestions, but still get the error.
And if I remove the executeBatch call, I also get a
ConnectionManager is not in Transaction exception
when the transaction is committed.
Is there a way to find out what changes might have
been made? Have there been bug reports?
I copied my original code from
org.apache.ojb.broker.BatchModeTest, by the
way, which is where I got the executeBatch call.
This is what is shown in that code.
And the javadoc definitely implies that
you can set the batch mode at runtime.
thanks,
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 4:58 PM
To: OJB Users List
Subject: Re: problems with batch-mode=true
Hi Bonnie,
Hope I can sheed some light on the 'problem'.
does this mean that you can't set batch mode to true
if it is set to false in repository_database.xml?
yep!
I think this behaviour has a big advantage, because it is
easy to disable batch-mode by set batch-mode false in
repository (if we don't have a bug in handling bach-mode ;-))
...
I am trying to insert records in batch mode. Perhaps I
don't understand
how this
works. Here is my test code to insert 100 customers :
Assume you have set batch-mode 'true' in repository
file. Then you have to enable batch mode for the use
PB instance.
Try this:
ConnectionManagerIF conMan =
broker.serviceConnectionManager();
try
{
broker.beginTransaction();
== broker.connectionManager.setBachMode(true);
now the PB instance is running in batch-mode till you set
false or the PB instance was closed.
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
conMan.executeBatch();
think you don't need executeBatch before commit, this will be done
at commit.
broker.commitTransaction();
}
If you still have problems with batch-mode try CVS-head. I think
Oleg has checked in some changes (but I'm not sure)
regards,
Armin
When I run this with batch-mode=false, it works
perfectly, although it
generates a SELECT and a
DELETE for every INSERT (which seems rather inefficient).
I imagine this
has something to do with
an M:N nondecomposed relationship which involves Customer records.
When I run this with batch-mode=true, it fails. I get
the following
exception
java.lang.IllegalArgumentException: object is not an instance of
declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHa
ndler.doExec
ute(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHa
ndler.invoke
(Unknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.execut
eBatch(Unkno
wn Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(
CustomerMigr
ation.java:68)
rethrown as
org.apache.ojb.broker.accesslayer.OJBBatchUpdateException:
object is not an instance of declaring class
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.execut
eBatch(Unkno
wn Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(
CustomerMigr
ation.java:68)
when conMan.executeBatch() is called.
Am I doing something wrong here? I am using rc4, with
MSSqlServer and
JSQLConnect.
thanks,
Bonnie MacKellar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
batch mode
I'm trying to write a utility that does batch inserts. In my code,
I get the connection manager and then set the batch mode to 'true'.
ConnectionManagerIF conMan = broker.serviceConnectionManager();
boolean saveBatchMode = conMan.isBatchMode();
try
{
conMan.setBatchMode(true);
Then I open a transaction and do the inserts. Looking at the output in
spy.log,
I notice that the inserts are interleaved with selects and deletes. Why does
OJB do this? And does this affect the batching? Are my inserts being done in
a batch or not. I can't tell from the log.
I am using rc4, by the way, with the Persistencebroker API, and MSSqlServer,
and the JSqlConnect driver.
Here is some of the spy.log output
1066659968660|70|0|statement|SELECT
firstName,customerID,type,rowVersion,customerNumber,deleteTag,dateEnrolled,d
eleteTagSetDate,customerName,lastName,subtype,status,address3,address2,addre
ss1,enrollingUserID,middleName,title FROM Customer WHERE customerID = ?
|SELECT
firstName,customerID,type,rowVersion,customerNumber,deleteTag,dateEnrolled,d
eleteTagSetDate,customerName,lastName,subtype,status,address3,address2,addre
ss1,enrollingUserID,middleName,title FROM Customer WHERE customerID = '2'
1066659968680|10|0|statement|INSERT INTO Customer
(customerID,rowVersion,firstName,middleName,lastName,title,address1,address2
,address3,customerNumber,customerName,type,subtype,deleteTag,deleteTagSetDat
e,status,enrollingUserID,dateEnrolled) VALUES
(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) |INSERT INTO Customer
(customerID,rowVersion,firstName,middleName,lastName,title,address1,address2
,address3,customerNumber,customerName,type,subtype,deleteTag,deleteTagSetDat
e,status,enrollingUserID,dateEnrolled) VALUES
('2','1','Big','','Customer','','','','','1000','BadCorporation','','','fals
e','','','0','')
1066659968710|30|0|statement|DELETE FROM EnrolledForPayment WHERE
customerID=?|DELETE FROM EnrolledForPayment WHERE customerID='2'
1066659968710|0|0|statement|SELECT
firstName,customerID,type,rowVersion,customerNumber,deleteTag,dateEnrolled,d
eleteTagSetDate,customerName,lastName,subtype,status,address3,address2,addre
ss1,enrollingUserID,middleName,title FROM Customer WHERE customerID = ?
|SELECT
firstName,customerID,type,rowVersion,customerNumber,deleteTag,dateEnrolled,d
eleteTagSetDate,customerName,lastName,subtype,status,address3,address2,addre
ss1,enrollingUserID,middleName,title FROM Customer WHERE customerID = '3'
1066659968710|0|0|statement|INSERT INTO Customer
(customerID,rowVersion,firstName,middleName,lastName,title,address1,address2
,address3,customerNumber,customerName,type,subtype,deleteTag,deleteTagSetDat
e,status,enrollingUserID,dateEnrolled) VALUES
(?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) |INSERT INTO Customer
(customerID,rowVersion,firstName,middleName,lastName,title,address1,address2
,address3,customerNumber,customerName,type,subtype,deleteTag,deleteTagSetDat
e,status,enrollingUserID,dateEnrolled) VALUES
('3','1','Big','','Customer','','','','','1001','BadCorporation','','','fals
e','','','0','')
1066659968710|0|0|statement|DELETE FROM EnrolledForPayment WHERE
customerID=?|DELETE FROM EnrolledForPayment WHERE customerID='3'
thanks,
Bonnie MacKellar
problems with batch-mode=true
I am trying to insert records in batch mode. Perhaps I don't understand how
this
works. Here is my test code to insert 100 customers :
ConnectionManagerIF conMan = broker.serviceConnectionManager();
try
{
broker.beginTransaction();
for (int i = 0; i 100; i++)
{
CustomerInterface customer = new Customer();
customer.setCustomerNumber(100 + i);
customer.setFirstName(Big);
customer.setLastName(Customer);
customer.setCustomerName(BadCorporation);
customer.setDeleteTag(Boolean.FALSE);
broker.store(customer);
}
conMan.executeBatch();
broker.commitTransaction();
}
When I run this with batch-mode=false, it works perfectly, although it
generates a SELECT and a
DELETE for every INSERT (which seems rather inefficient). I imagine this has
something to do with
an M:N nondecomposed relationship which involves Customer records.
When I run this with batch-mode=true, it fails. I get the following
exception
java.lang.IllegalArgumentException: object is not an instance of declaring
class
at java.lang.reflect.Method.invoke(Native Method)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.doExecut
e(Unknown Source)
at
org.apache.ojb.broker.util.batch.PreparedStatementInvocationHandler.invoke(U
nknown Source)
at $Proxy0.doExecute(Unknown Source)
at
org.apache.ojb.broker.util.batch.BatchConnection.executeBatch(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.executeBatch(Unknown
Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:68)
rethrown as org.apache.ojb.broker.accesslayer.OJBBatchUpdateException:
object is not an instance of declaring class
at
org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.executeBatch(Unknown
Source)
at
com.mobius.activebill.dbmigrationutils.CustomerMigration.main(CustomerMigrat
ion.java:68)
when conMan.executeBatch() is called.
Am I doing something wrong here? I am using rc4, with MSSqlServer and
JSQLConnect.
thanks,
Bonnie MacKellar
RE: rollback problem
Yes, it seems to be. We have had no problems with rollback since.
But I am concerned about using ConnectionFactoryPooledImpl
with Weblogic and a data source. The comments in ojb.properties
seem to imply that I should only be using ConnectionFactoryManagedImpl.
And thinking about it, I am concerned about the implications
of using OJB pooling on top of Weblogic connection pooling.
thanks,
Bonnie MacKellar
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2003 8:16 PM
To: OJB Users List
Subject: Re: rollback problem
Hi Bonnie,
is this problem solved by
setting
useAutoCommit=1
as you posted in an later mail?
regards,
Armin
On Thu, 2 Oct 2003 15:54:28 -0400, Bonnie MacKellar
[EMAIL PROTECTED]
wrote:
Hi,
I have a simple two step transaction, in which two inserts
occur. I am
using
PB broker, with OJB transactions. I am connecting to a data
source in
Weblogic. I am using rc4.
When a rollback occurs, the first record inserted in the
transaction is
not
removed. This is very incorrect, of course. I looked back
in the archives
for this list, and found a message saying not to use
ConnectionFactoryManagedImpl if you are using OJB
transactions. Fine. So
I
switched to ConnectionFactoryPooledImpl. But the problem
remains. Is
there a
known problem with this?
My code is
try
{
broker.beginTransaction();
broker.store(customer);
broker.store(audit);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
logger.error(e.getMessage());
}
}
I am attaching my ojb.properties as well.
Thanks,
Bonnie MacKellar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: ConnectionfactoryPooledImpl in Weblogic, was rollback proble m
OK, I see that my questions did get answered. Thanks.
1. On the documentation - yes, reading that section is still
unclear. It still seems to say to me that one must set useAutoCommit=0
when using data sources. Also, a small quibble - but a section heading
for each attribute would be REALLY useful, along with a table of contents.
It is so hard to find the information one needs in the documentation.
2. So what you are saying is that if the ConnectionFactory implementation
detects that it is using a datasource, it turns off pooling? Is that the
case? Or does something else determine whether it pools or not?
thanks,
Bonnie MacKellar
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 07, 2003 8:16 PM
To: OJB Users List
Subject: Re: ConnectionfactoryPooledImpl in Weblogic, was rollback
problem
Hi Bonnie,
On Mon, 6 Oct 2003 13:27:44 -0400, Bonnie MacKellar
[EMAIL PROTECTED]
wrote:
No one answered this, but I did find my problem - I needed to set
useAutoCommit=1 in my repository_database.xml file
is the docmentation in
http://db.apache.org/ojb/repository.html#jdbc-connection-descriptor
mistakable?
However, I need to understand something. If I am running in
Weblogic,
using
a connection pooled data source,
but NOT using EJBs, and NOT using JTA, is it safe to use
ConnectionFactoryPooledImpl?
yes, because all shipped ConnectionFactory implementation
do not pool DataSources. When using DataSource OJB assume
that the pooling is done by the emittent of the DataSources.
Will this cause problems for me down the line? I am feeling
very unsure
of
this
configuration.
I don't see any problems in the described
situation
...NOT using EJBs, and NOT using JTA,
regards,
Armin
thanks,
Bonnie MacKellar
-Original Message-
From: Bonnie MacKellar
Sent: Thursday, October 02, 2003 3:54 PM
To: '[EMAIL PROTECTED] '
Subject: rollback problem
Hi,
I have a simple two step transaction, in which two inserts
occur. I am
using
PB broker, with OJB transactions. I am connecting to a data
source in
Weblogic. I am using rc4.
When a rollback occurs, the first record inserted in the
transaction is
not
removed. This is very incorrect, of course. I looked back
in the archives
for this list, and found a message saying not to use
ConnectionFactoryManagedImpl if you are using OJB
transactions. Fine. So
I
switched to ConnectionFactoryPooledImpl. But the problem
remains. Is
there a
known problem with this?
My code is
try
{
broker.beginTransaction();
broker.store(customer);
broker.store(audit);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
logger.error(e.getMessage());
}
}
I am attaching my ojb.properties as well.
Thanks,
Bonnie MacKellar
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ConnectionfactoryPooledImpl in Weblogic, was rollback problem
No one answered this, but I did find my problem - I needed to set
useAutoCommit=1 in my repository_database.xml file
However, I need to understand something. If I am running in Weblogic, using
a connection pooled data source,
but NOT using EJBs, and NOT using JTA, is it safe to use
ConnectionFactoryPooledImpl?
Will this cause problems for me down the line? I am feeling very unsure of
this
configuration.
thanks,
Bonnie MacKellar
-Original Message-
From: Bonnie MacKellar
Sent: Thursday, October 02, 2003 3:54 PM
To: '[EMAIL PROTECTED] '
Subject: rollback problem
Hi,
I have a simple two step transaction, in which two inserts occur. I am using
PB broker, with OJB transactions. I am connecting to a data source in
Weblogic. I am using rc4.
When a rollback occurs, the first record inserted in the transaction is not
removed. This is very incorrect, of course. I looked back in the archives
for this list, and found a message saying not to use
ConnectionFactoryManagedImpl if you are using OJB transactions. Fine. So I
switched to ConnectionFactoryPooledImpl. But the problem remains. Is there a
known problem with this?
My code is
try
{
broker.beginTransaction();
broker.store(customer);
broker.store(audit);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
logger.error(e.getMessage());
}
}
I am attaching my ojb.properties as well.
Thanks,
Bonnie MacKellar
RE: OJB / MS SQL Server
We're using MSQQLServer with the JSQLConnect driver without any major problems. But that is not a free driver... Bonnie MacKellar -Original Message- From: LAURENT Stephane To: OJB Users List Sent: 8/20/03 10:18 AM Subject: OJB / MS SQL Server Hi, is anybody working with SQL Server 7 ? can't find free JDBC driver working fine ... can you send me your repository_database and where to find good driver ? Microsoft's driver work only with SQL Server2000, where can I find V7 compatible version ? actualy use com.jnetdirect.jsql.JSQLDriver, but without connection pool to stay on free licence. Help please ! Thanks - Original Message - From: Michael Becke [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 2:34 PM Subject: Re: Configure OJB in WAS Testenvironment Oliver, The WebSphereTransactionManagerFactory included in RC4 does not work in WAS 4. This has been fixed in the latest version in CVS. Mike On Wednesday, August 20, 2003, at 05:24 AM, [EMAIL PROTECTED] wrote: Hi to all, can anybody please tell me how OJB has to be configured to use the Webshere Application Server connection pooling? We are using the WAS 4.03 Testenvironment and OJB RC4. The following configuration is used: - OJB-properties: ... --- -- # ConnectionFactory / Default ConnectionPool #-- -- ConnectionFactoryClass=org.apache.ojb.broker.accesslayer.ConnectionFact oryManagedImpl ... #-- -- # Transaction Management and assocation #-- -- OJBTxManagerClass=org.apache.ojb.odmg.JTATxManager JTATransactionManagerClass=org.apache.ojb.odmg.transaction.WebSphereTra nsactionManagerFactory ... - repository_database.xml jdbc-connection-descriptor jcd-alias=default default-connection=true platform=Db2 jdbc-level=2.0 protocol=jdbc subprotocol=db2 dbalias=LSI1 username=myname password=mypassword eager-release=false batch-mode=false useAutoCommit=1 ignoreAutoCommitExceptions=false connection-pool maxActive=21 validationQuery= / sequence-manager className =org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl attribute attribute-name=grabSize attribute-value =20/ attribute attribute-name=autoNaming attribute-value =true/ attribute attribute-name=globalSequenceId attribute-value=false/ attribute attribute-name=globalSequenceStart attribute-value=1/ /sequence-manager /jdbc-connection-descriptor Here is the code : PersistenceBroker broker; Query q; Collection results; broker = PersistenceBrokerFactory.defaultPersistenceBroker (); broker.beginTransaction(); and we get the following exception in broker.beginTransaction: IEx=UnsupportedOperationException detailMessage=Not supported in managed environment Thanks a lot. Oliver Remark: Using the OJB connection Pooling everything works fine! - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
updates not working with optimistic locking
) at com.jnetdirect.jsql.ag.i(Unknown Source) at com.jnetdirect.jsql.ag.new(Unknown Source) at com.jnetdirect.jsql.ag.int(Unknown Source) at com.jnetdirect.jsql.ap.executeUpdate(Unknown Source) at com.p6spy.engine.logging.P6LogPreparedStatement.executeUpdate(P6LogPreparedS tatement.java:182) at weblogic.jdbc.pool.Statement.executeUpdate(Statement.java:304) at weblogic.jdbc.rmi.internal.PreparedStatementImpl.executeUpdate(PreparedState mentImpl.java:68) at weblogic.jdbc.rmi.SerialPreparedStatement.executeUpdate(SerialPreparedStatem ent.java:58) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.store(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown Source) at dbtests.AccountUpdater.run(AccountUpdater.java:47) 18867 INFO [Thread-11] accesslayer.ConnectionManagerImpl - Rollback was called, do rollback on current connection [EMAIL PROTECTED] - The relevant part of repository_user.xml looks like !-- Definitions for Account table -- class-descriptor class=com.mobius.activebill.persistentobjects.Account table=Account field-descriptor name=accountID column=accountID jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor name=rowVersion column=rowVersion jdbc-type=INTEGER locking=true / field-descriptor name=accountNumber column=accountNumber jdbc-type=VARCHAR / field-descriptor name=deleteTag column=deleteTag jdbc-type=BIT / field-descriptor name=deleteTagSetDate column=deleteTagSetDate jdbc-type=TIMESTAMP / field-descriptor name=isDisconnected column=isDisconnected jdbc-type=BIT / field-descriptor name=telephoneNumber column=telephoneNumber jdbc-type=VARCHAR / field-descriptor name=serviceType column=serviceType jdbc-type=VARCHAR / field-descriptor name=billingCycle column=billingCycle jdbc-type=VARCHAR / field-descriptor name=customerID column=customerID jdbc-type=INTEGER / reference-descriptor name=customer class-ref=com.mobius.activebill.persistentobjects.Customer proxy=true foreignkey field-ref=customerID/ /reference-descriptor collection-descriptor name=users element-class-ref=com.mobius.activebill.persistentobjects.User auto-retrieve=true auto-update=false indirection-table=Custodian fk-pointing-to-this-class column=accountID / fk-pointing-to-element-class column=userID / /collection-descriptor collection-descriptor name=bills element-class-ref=com.mobius.activebill.persistentobjects.Bill proxy=true inverse-foreignkey field-ref=accountID/ /collection-descriptor /class-descriptor thanks, Bonnie MacKellar
updates and optimistic locking
I must be doing something really wrong, because when I write code that
I THINK should generate an update statement, an insert statement is
generated instead. I am trying to use optimistic locking. I recalled
that there was a bug that involved optimistic locking and updates, so
I downloaded and built the most recent code from the CVS, and
still the wrong queries are generated.
This is the code that I think should cause an update :
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
AccountInterface acc = retrieveAccountByNumber(1234);
acc.setTelephoneNumber(555-);
broker.store(acc);
broker.commitTransaction();
This is what is actually generated (from spy.log)
1058821254048|201|27|statement|SELECT
accountID,isDisconnected,serviceType,deleteTag,customerID,deleteTagSetDate,t
elephoneNumber,accountNumber,rowVersion,billingCycle FROM Account WHERE
accountID = ? |SELECT
accountID,isDisconnected,serviceType,deleteTag,customerID,deleteTagSetDate,t
elephoneNumber,accountNumber,rowVersion,billingCycle FROM Account WHERE
accountID = '5'
1058821254658|781|21|statement|INSERT INTO Account
(accountID,rowVersion,accountNumber,deleteTag,deleteTagSetDate,isDisconnecte
d,telephoneNumber,serviceType,billingCycle,customerID) VALUES
(?,?,?,?,?,?,?,?,?,?) |INSERT INTO Account
(accountID,rowVersion,accountNumber,deleteTag,deleteTagSetDate,isDisconnecte
d,telephoneNumber,serviceType,billingCycle,customerID) VALUES
('1','0','1234','false','','','555-','','','0')
1058821254678|0|21|rollback||
Since the record alreayd exists, an exception is thrown and the transaction
rolls back.
Is my code completely wrong? I thought I had understood the tutorial.
Thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
patch for optimistic locking bug?
I recall there was a bug with updates and optimistic locking, and a patch was submitted. How would I go about getting that patch? I seem to be running smack into the bug. I took a look at the CVS stuff, but I am not really sure how to navigate it. thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
RE: Weblogic, threads, and startup errors
Hi, I was out yesterday, so I just read this. This is an excellent explanation. When I encountered the problem, I very much suspected it was something like you were describing. But I was not sure, and in particular, I was not sure what the right fix might be. Thanks! Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 10:29 AM To: 'OJB Users List' Subject: RE: Weblogic, threads, and startup errors Hi Bonnie, Well classloaders, especially in servlet containers, are not always the most predictable things. I am not sure if the classloader of threads started from a web application is even really covered in any length in the servlet specification. So let's look at the javadocs of Thread.getContextClassLoader() for an idea of how this classloader craziness is supposed to work: Returns the context ClassLoader for this Thread. The context ClassLoader is provided by the creator of the thread for use by code running in this thread when loading classes and resources. If not set, the default is the ClassLoader context of the parent Thread. The context ClassLoader of the primordial thread is typically set to the class loader used to load the application. First, if there is a security manager, and the caller's class loader is not null and the caller's class loader is not the same as or an ancestor of the context class loader for the thread whose context class loader is being requested, then the security manager's checkPermission method is called with a RuntimePermission(getClassLoader) permission to see if it's ok to get the context ClassLoader. If not set, the default is the ClassLoader context of the parent Thread. Based on this statement on starting a new thread, you would expect it's classloader to be the same as the parent classloader of the thread it was started from. However, this is obviously not the case within Weblogic. You would expect, (hope), the a new thread started from a servlet would use the webapp's classloader, i.e. the parent classloader that the servlet is using. However, it is obvious that the classloader given to new threads started within Weblogic is not the same classloader as the one possessed by the servlet. My guess is that new threads are using either the system of the container or the primordial classloader rather than the webapp's classloader. So, based on the statement The context ClassLoader is provided by the creator of the thread for use by code running in this thread when loading classes and resources. It is probably a best practice to make sure you always set the classloader of a new thread before starting. By using this process you have guaranteed the behavior of the new thread's classloader. In closing, my guess on what is currently happening is that new threads are either using the system classloader of the container or the primordial classloader rather than the webapp's classloader. *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:27 PM To: OJB Users List Subject: RE: Weblogic, threads, and startup errors This did the trick. Thank you! Now I just have to understand WHY it did the trick :-) Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:23 PM To: 'OJB Users List' Subject: RE: Weblogic, threads, and startup errors Actually, it should look like thisL ClassLoader cl = Thread.currentThread().getContextClassLoader(); AccountUpdater myNewThread = new AccountUpdater(); myNewThread.setContextClassLoader(cl); myNewThreadStart.start(); *===* * Scott T Weaver * * Jakarta Jetspeed Portal Project * * [EMAIL PROTECTED] * *===* -Original Message- From: Weaver, Scott [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:21 PM To: 'OJB Users List' Subject: RE: Weblogic, threads, and startup errors Some simple questions: 1. Where do you have the OJB resources (OJB.properties, repository.xml, etc.)? To make things easy, they should be in the default package of your webapp's WEB-INF/classes directory. 2. Where is your OJB jar? For the most predictable results, it should be in your webapp's WEB-INF/lib directory. I would discourage loading OJB from shared or common lib locations within your
Weblogic, threads, and startup errors
I posted a question on Thursday about a mysterious error I am getting when I try to obtain a broker in a thread spawned within my application. It was not answered, perhaps because of the holiday, or perhaps because no one else is doing what we are doing. We are running a servlet based application in Weblogic. I am using rc2 at the moment. As long as I obtain the broker in the main thread, there is no problem. But if I spawn a new thread and try to obtain the broker, I was getting obvious classpath problems - OJB.properties not found, and so forth. I explicitly placed the classpath info for the app in my Weblogic startup file (not good, but I will try anything right now). Doing this, it does find the OJB.properties file, but now I get another odd error : [BOOT] ERROR: The specified class org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl does not implement the interface org.apache.ojb.broker.cache.ObjectCache, which is a requirement for the key ObjectCacheClass. Using default class org.apache.ojb.broker.cache.ObjectCacheDefaultImpl java.lang.NullPointerException at dbtests.AccountUpdater.run(AccountUpdater.java:68) Has anybody ever encountered this error before? Obviously, something goes hideously wrong with the configuration of OJB once threads get into the picture, but what? And again, I do not have this problem as long as the code to obtain the broker is situated in the main thread. thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
RE: Weblogic, threads, and startup errors
Well, that is precisely why I was trying this - to ensure that I have
no brokers spanning threads.
My code looks like this :
public class AccountUpdater extends Thread
{
private PersistenceBroker broker = null;
public void run()
{
try
{
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(new
PBKey(ActiveBill));
broker.beginTransaction();
AccountInterface acc = retrieveAccountByNumber(1234);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
System.out.print(e.getMessage());
e.printStackTrace();
}
finally {
broker.close();
}
}
The exception is thrown right at the createPersistenceBroker step. If I run
this so that a new thread is not spawned, there is no problem. But if I
spawn a thread and then call this code, I get the exception.
Again, I need to do this in order to avoid long lived brokers.
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Edson Carlos Ericksson Richter
[mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:30 PM
To: OJB Users List
Subject: Re: Weblogic, threads, and startup errors
I don't know about you, but I had all kind of strange errors
working with
long time broker lives...
Now, I'm working as in mnemonic code:
public void xyzStore( XYZObject o ) {
broker = getBroker();
try {
broker.store( o );
} catch() {
}finally {
broker.close(); // this guarantees no mistakes...
}
}
This guarantees that the broker object isn't spawned along
threads... And my
code works fine!
Since the brokers are maintained in a pool, there is not pain
in performance
(AFAIK).
Edson Richter
- Original Message -
From: Bonnie MacKellar [EMAIL PROTECTED]
To: OJB Users List (E-mail) [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:20 PM
Subject: Weblogic, threads, and startup errors
I posted a question on Thursday about a mysterious error I am
getting when I
try to obtain a broker in a thread spawned within my
application. It was not
answered, perhaps because of the holiday, or perhaps because
no one else is
doing what we are doing.
We are running a servlet based application in Weblogic. I am
using rc2 at
the moment. As long as I obtain the broker in the main
thread, there is no
problem. But if I spawn a new thread and try to obtain the
broker, I was
getting obvious classpath problems - OJB.properties not
found, and so forth.
I explicitly placed the classpath info for the app in my
Weblogic startup
file (not good, but I will try anything right now). Doing
this, it does find
the OJB.properties file, but now I get another odd error :
[BOOT] ERROR: The specified class
org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl does
not implement
the interface org.apache.ojb.broker.cache.ObjectCache, which is a
requirement for the key ObjectCacheClass. Using default class
org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
java.lang.NullPointerException
at dbtests.AccountUpdater.run(AccountUpdater.java:68)
Has anybody ever encountered this error before? Obviously,
something goes
hideously wrong with the configuration of OJB once threads
get into the
picture, but what? And again, I do not have this problem as
long as the code
to obtain the broker is situated in the main thread.
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 4/7/2003
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weblogic, threads, and startup errors
1) yes, they are in WEB-INF/classes
2) yes, it is in WEB-INF/lib
3) I will try this...
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Weaver, Scott [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:21 PM
To: 'OJB Users List'
Subject: RE: Weblogic, threads, and startup errors
Some simple questions:
1. Where do you have the OJB resources (OJB.properties,
repository.xml, etc.)? To make things easy, they should be
in the default package of your webapp's WEB-INF/classes directory.
2. Where is your OJB jar? For the most predictable results,
it should be in your webapp's WEB-INF/lib directory. I would
discourage loading OJB from shared or common lib locations
within your container as this might be a source of class
loader errors.
You may want to try setting the context classloader of your
new Thread with the context classloader of your servlet's
current thread and see if that helps.
In your servlet try this...
ClassLoader cl = Thread.currentThread().getContextClassLoader();
AccountUpdater myNewThread = new Thread();
myNewThread.setContextClassLoader(cl);
myNewThreadStart.start();
*===*
* Scott T Weaver *
* Jakarta Jetspeed Portal Project *
* [EMAIL PROTECTED] *
*===*
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:01 PM
To: OJB Users List
Subject: RE: Weblogic, threads, and startup errors
You are right in your analysis, but in fact, the code I
just gave you is
newer code that
I put together to try to see if defaultPersistenceBroker
might be the
problem. My original code (which generated the exception)
looks exactly
like your code below!!
The problem is more fundamental than this. It is something
to do with
the interaction of Weblogic, OJB startup code, and threading.
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Edson Carlos Ericksson Richter
[mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:56 PM
To: OJB Users List
Subject: Re: Weblogic, threads, and startup errors
I'm being analizing your code... Well, I get my broker using
PersistenceBrokerFactory.defaultPersistenceBroker()
Have you tried to work with defaultPersistenceBroker()? I
know that in some
release (I don't know what) things was changed in the way OJB
is getting the
.xml based on this config... Then you can evolute to a
createPersistenceBroker after this is working...
Another point: you are declaring a object scoped broker in
public class AccountUpdater extends Thread
{
private PersistenceBroker broker = null;
but in the run method, you are not filling in because you are
declaring a
new try scoped broker:
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(new
PBKey(ActiveBill));
You can test making in the following way:
public class AccountUpdater extends Thread
{
//private PersistenceBroker broker = null; // This line
is being removed
in favor of a parameter for retrieveAccountByNumber...
public void run()
{
try
{
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
AccountInterface acc =
retrieveAccountByNumber(broker, 1234);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
System.out.print(e.getMessage());
e.printStackTrace();
}
finally {
broker.close();
}
}
Don't forget to change the retrive... to use the parameter you are
sending...
Another point that could you check is use rc3 or download cvs
HEAD to build
a near rc4 bin. They are far stable than previous versions...
My2c,
Edson Richter
- Original Message -
From: Bonnie MacKellar [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:36 PM
Subject: RE: Weblogic, threads, and startup errors
Well, that is precisely why I was trying this - to ensure
that I have
no brokers spanning threads.
My code looks like this :
public class AccountUpdater extends Thread
{
private PersistenceBroker broker = null;
public void run()
{
try
{
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(new
PBKey(ActiveBill
RE: Weblogic, threads, and startup errors
I absolutely think you are right. However, I am not
much of a Weblogic expert either, nor am I much
of an OJB expert :-(.
Trying to understand the interaction is very difficult.
I am really just hoping someone else has had (and
fixed) this problem. It must be pretty common, I would
think.
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:15 PM
To: OJB Users List
Subject: Re: Weblogic, threads, and startup errors
Hi,
I'm not an expert in web-environments, but this
seems like a ClassLoader problem.
The thread's ClassLoader try to initialize
OJB again.
Maybe you have to associate the new created
thread with the 'right' ClassLoader using
thread.setContextClassLoader(...)???
Maybe I'm completely wrong ;-)
regards,
Armin
- Original Message -
From: Bonnie MacKellar [EMAIL PROTECTED]
To: OJB Users List [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 10:36 PM
Subject: RE: Weblogic, threads, and startup errors
Well, that is precisely why I was trying this - to ensure
that I have
no brokers spanning threads.
My code looks like this :
public class AccountUpdater extends Thread
{
private PersistenceBroker broker = null;
public void run()
{
try
{
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(new
PBKey(ActiveBill));
broker.beginTransaction();
AccountInterface acc = retrieveAccountByNumber(1234);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
System.out.print(e.getMessage());
e.printStackTrace();
}
finally {
broker.close();
}
}
The exception is thrown right at the
createPersistenceBroker step. If
I run
this so that a new thread is not spawned, there is no
problem. But if
I
spawn a thread and then call this code, I get the exception.
Again, I need to do this in order to avoid long lived brokers.
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Edson Carlos Ericksson Richter
[mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:30 PM
To: OJB Users List
Subject: Re: Weblogic, threads, and startup errors
I don't know about you, but I had all kind of strange errors
working with
long time broker lives...
Now, I'm working as in mnemonic code:
public void xyzStore( XYZObject o ) {
broker = getBroker();
try {
broker.store( o );
} catch() {
}finally {
broker.close(); // this guarantees no mistakes...
}
}
This guarantees that the broker object isn't spawned along
threads... And my
code works fine!
Since the brokers are maintained in a pool, there is not pain
in performance
(AFAIK).
Edson Richter
- Original Message -
From: Bonnie MacKellar [EMAIL PROTECTED]
To: OJB Users List (E-mail) [EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:20 PM
Subject: Weblogic, threads, and startup errors
I posted a question on Thursday about a mysterious error I am
getting when I
try to obtain a broker in a thread spawned within my
application. It was not
answered, perhaps because of the holiday, or perhaps because
no one else is
doing what we are doing.
We are running a servlet based application in Weblogic. I am
using rc2 at
the moment. As long as I obtain the broker in the main
thread, there is no
problem. But if I spawn a new thread and try to obtain the
broker, I was
getting obvious classpath problems - OJB.properties not
found, and so forth.
I explicitly placed the classpath info for the app in my
Weblogic startup
file (not good, but I will try anything right now). Doing
this, it does find
the OJB.properties file, but now I get another odd error :
[BOOT] ERROR: The specified class
org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl does
not implement
the interface org.apache.ojb.broker.cache.ObjectCache, which is a
requirement for the key ObjectCacheClass. Using default class
org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
java.lang.NullPointerException
at dbtests.AccountUpdater.run(AccountUpdater.java:68)
Has anybody ever encountered this error before? Obviously,
something goes
hideously wrong with the configuration of OJB once threads
get into the
picture, but what? And again, I do not have this problem as
long as the code
to obtain the broker is situated in the main thread.
thanks,
Bonnie MacKellar
software engineer
Mobius Management Systems
RE: Weblogic, threads, and startup errors
This did the trick. Thank you! Now I just have to
understand WHY it did the trick :-)
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Weaver, Scott [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:23 PM
To: 'OJB Users List'
Subject: RE: Weblogic, threads, and startup errors
Actually, it should look like thisL
ClassLoader cl = Thread.currentThread().getContextClassLoader();
AccountUpdater myNewThread = new AccountUpdater();
myNewThread.setContextClassLoader(cl);
myNewThreadStart.start();
*===*
* Scott T Weaver *
* Jakarta Jetspeed Portal Project *
* [EMAIL PROTECTED] *
*===*
-Original Message-
From: Weaver, Scott [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:21 PM
To: 'OJB Users List'
Subject: RE: Weblogic, threads, and startup errors
Some simple questions:
1. Where do you have the OJB resources (OJB.properties,
repository.xml,
etc.)? To make things easy, they should be in the default
package of your
webapp's WEB-INF/classes directory.
2. Where is your OJB jar? For the most predictable
results, it should be
in your webapp's WEB-INF/lib directory. I would discourage
loading OJB
from shared or common lib locations within your container
as this might be
a source of class loader errors.
You may want to try setting the context classloader of your
new Thread
with the context classloader of your servlet's current
thread and see if
that helps.
In your servlet try this...
ClassLoader cl = Thread.currentThread().getContextClassLoader();
AccountUpdater myNewThread = new Thread();
myNewThread.setContextClassLoader(cl);
myNewThreadStart.start();
*===*
* Scott T Weaver *
* Jakarta Jetspeed Portal Project *
* [EMAIL PROTECTED] *
*===*
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 5:01 PM
To: OJB Users List
Subject: RE: Weblogic, threads, and startup errors
You are right in your analysis, but in fact, the code I
just gave you is
newer code that
I put together to try to see if defaultPersistenceBroker
might be the
problem. My original code (which generated the exception)
looks exactly
like your code below!!
The problem is more fundamental than this. It is
something to do with
the interaction of Weblogic, OJB startup code, and threading.
Bonnie MacKellar
software engineer
Mobius Management Systems, Inc.
[EMAIL PROTECTED]
-Original Message-
From: Edson Carlos Ericksson Richter
[mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 4:56 PM
To: OJB Users List
Subject: Re: Weblogic, threads, and startup errors
I'm being analizing your code... Well, I get my broker using
PersistenceBrokerFactory.defaultPersistenceBroker()
Have you tried to work with defaultPersistenceBroker()? I
know that in some
release (I don't know what) things was changed in the way OJB
is getting the
.xml based on this config... Then you can evolute to a
createPersistenceBroker after this is working...
Another point: you are declaring a object scoped broker in
public class AccountUpdater extends Thread
{
private PersistenceBroker broker = null;
but in the run method, you are not filling in because you are
declaring a
new try scoped broker:
PersistenceBroker broker =
PersistenceBrokerFactory.createPersistenceBroker(new
PBKey(ActiveBill));
You can test making in the following way:
public class AccountUpdater extends Thread
{
//private PersistenceBroker broker = null; // This line
is being removed
in favor of a parameter for retrieveAccountByNumber...
public void run()
{
try
{
PersistenceBroker broker =
PersistenceBrokerFactory.defaultPersistenceBroker();
broker.beginTransaction();
AccountInterface acc =
retrieveAccountByNumber(broker, 1234);
broker.commitTransaction();
}
catch (Exception e)
{
broker.abortTransaction();
System.out.print(e.getMessage());
e.printStackTrace();
}
finally {
broker.close();
}
}
Don't forget to change the retrive... to use the
parameter you are
sending...
Another point that could you check is use rc3 or download cvs
HEAD to build
a near rc4 bin. They are far stable than previous versions
optimistic locking and decomposed M:N relationships
I am adding optimistic locking to my database, using integer version fields in each table. I notice that it does not seem to work with tables implementing M:N relationships (I am using the decomposed style). I get this error : com.jnetdirect.jsql.w: Cannot insert the value NULL into column 'rowVersion', table 'ActiveBill.dbo.Custodian'; Custodian implements the M:N relationship between users and accounts. Does this mean that I should omit the version fields in M:N relationship tables? How will locking be handled for such tables? Here is the repository information for the tables in question : !-- Definitions for User table -- class-descriptor class=com.mobius.activebill.persistentobjects.User table=ActiveBillUser field-descriptor name=userID column=userID jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor name=rowVersion column=rowVersion jdbc-type=INTEGER locking=true / ... stuff omitted... collection-descriptor name=accounts element-class-ref=com.mobius.activebill.persistentobjects.Account auto-retrieve=true auto-update=false indirection-table=Custodian fk-pointing-to-this-class column=userID / fk-pointing-to-element-class column=accountID / /collection-descriptor /class-descriptor !-- Definitions for Account table -- class-descriptor class=com.mobius.activebill.persistentobjects.Account table=Account field-descriptor name=accountID column=accountID jdbc-type=INTEGER primarykey=true autoincrement=true / field-descriptor name=rowVersion column=rowVersion jdbc-type=INTEGER locking=true / field-descriptor name=accountNumber column=accountNumber jdbc-type=VARCHAR / field-descriptor name=customerID column=customerID jdbc-type=INTEGER / reference-descriptor name=customer class-ref=com.mobius.activebill.persistentobjects.Customer proxy=true foreignkey field-ref=customerID/ /reference-descriptor collection-descriptor name=users element-class-ref=com.mobius.activebill.persistentobjects.User auto-retrieve=true auto-update=false indirection-table=Custodian fk-pointing-to-this-class column=accountID / fk-pointing-to-element-class column=userID / /collection-descriptor collection-descriptor name=bills element-class-ref=com.mobius.activebill.persistentobjects.Bill proxy=true inverse-foreignkey field-ref=accountID/ /collection-descriptor /class-descriptor !-- Definitions for Custodian table -- class-descriptor class=com.mobius.activebill.persistentobjects.Custodian table=Custodian field-descriptor name=accountID column=accountID jdbc-type=INTEGER primarykey=true / field-descriptor name=rowVersion column=rowVersion jdbc-type=INTEGER locking=true / field-descriptor name=userID column=userID jdbc-type=INTEGER primarykey=true / reference-descriptor name=user class-ref=com.mobius.activebill.persistentobjects.User auto-retrieve=false foreignkey field-ref=userID/ /reference-descriptor reference-descriptor name=account class-ref=com.mobius.activebill.persistentobjects.Account auto-retrieve=false foreignkey field-ref=accountID/ /reference-descriptor /class-descriptor thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
confused by behavior of 1:n relationship
On Friday, I posted asking about a strange bug in my system. I never got any responses, but I did find the cause of the bug. The problem is, I don't understand the cause. I was hoping that someone who knows more about relationship and proxy behavior might enlighten me. I really need to understand this so I can not make these mistakes in the future. I have three classes : User, Customer, and PaymentTxn. At the point at which the strange behavior occurred, I had retrieved a user, using a criteria query, and was creating a PaymentTxn object. The User object has a reference to a Customer object, which I wanted to use in my new PaymentTxn object. The User object's reference was specified in the repository_user.xml file like this : field-descriptor name=customerID column=customerID jdbc-type=INTEGER / reference-descriptor name=customer class-ref=com.mobius.activebill.persistentobjects.Customer proxy=true foreignkey field-ref=customerID/ /reference-descriptor The reference in the PaymentTxn object is specified in the same way. When I tried to get the Customer via the User object by following the reference, the strange behavior occurred. I could get the Customer object, and print out its id properly. But when I tried to add it to the User object, the generated SQL got the customer id value wrong. When I changed the code so that I used a criteria based query to retrieve the Customer object, the generated SQL was fine. Why? What is the difference in behavior? The sequence of retrievals looks the same in either case. Here is the code that did not work : CustomerInterface customer = payer.getCustomer(); System.out.println(customer name is + customer.getName()); System.out.println(customer id is + customer.getID()); paymentTxn.setIssuingCustomer(customer); broker.store(paymentTxn); The name and id printed out correctly, but after calling setIssuingCustomer, the associated SQL insert statement had the wrong value (a 0) for customerID. But this code did work : CustomerInterface customer = retrieveCustomerByName(TheBigCustomer); System.out.println(customer name is + customer.getName()); System.out.println(customer id is + customer.getID()); paymentTxn.setIssuingCustomer(customer); broker.store(paymentTxn); The only difference is the way in which I obtained the customer. Why should this be different? thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
RE: confused by behavior of 1:n relationship
Sure, I understand that the customer returned in my first set of code is a proxy. But I thought that when I traverse the link, the entire object is retrieved. It certainly behaves that way. I can print out the name of the customer (part of the full business object) as can be seen from the code. I can also print out the correct customer ID. So why can't OJB take that same customerID value and stuff it in the generated INSERT query? That is what I don't get. I did not try using a non-proxied reference, but I bet it would work. I am trying to understand why. thanks, Bonnie -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2003 4:46 PM To: OJB Users List Subject: Re: confused by behavior of 1:n relationship hi bonnie, Bonnie MacKellar wrote: On Friday, I posted asking about a strange bug in my system. I never got any responses, but I did find the cause of the bug. The problem is, I don't understand the cause. I was hoping that someone who knows more about relationship and proxy behavior might enlighten me. I really need to understand this so I can not make these mistakes in the future. I have three classes : User, Customer, and PaymentTxn. At the point at which the strange behavior occurred, I had retrieved a user, using a criteria query, and was creating a PaymentTxn object. The User object has a reference to a Customer object, which I wanted to use in my new PaymentTxn object. The User object's reference was specified in the repository_user.xml file like this : field-descriptor name=customerID column=customerID jdbc-type=INTEGER / reference-descriptor name=customer class-ref=com.mobius.activebill.persistentobjects.Customer proxy=true have you tried to use a non-proxied reference-descriptor ? foreignkey field-ref=customerID/ /reference-descriptor The reference in the PaymentTxn object is specified in the same way. When I tried to get the Customer via the User object by following the reference, the strange behavior occurred. I could get the Customer object, and print out its id properly. But when I tried to add it to the User object, the generated SQL got the customer id value wrong. When I changed the code so that I used a criteria based query to retrieve the Customer object, the generated SQL was fine. Why? What is the difference in behavior? The sequence of retrievals looks the same in either case. Here is the code that did not work : CustomerInterface customer = payer.getCustomer(); System.out.println(customer name is + customer.getName()); System.out.println(customer id is + customer.getID()); paymentTxn.setIssuingCustomer(customer); broker.store(paymentTxn); The name and id printed out correctly, but after calling setIssuingCustomer, the associated SQL insert statement had the wrong value (a 0) for customerID. the customer referenced by payer.getCustomer is actually a proxy ! But this code did work : CustomerInterface customer = retrieveCustomerByName(TheBigCustomer); System.out.println(customer name is + customer.getName()); System.out.println(customer id is + customer.getID()); paymentTxn.setIssuingCustomer(customer); broker.store(paymentTxn); here the customer is a real business object (i assume you did not define proxy=true in the class-descriptor) The only difference is the way in which I obtained the customer. Why should this be different? thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] hth jakob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
error - wrong foreign key generated
I have two classes, PaymentTxn and Customer. PaymentTxn contains a foreign
key which points to Customer. When I create a new PaymentTxn, I set the
foreign key,
but the generated SQL gets the wrong value. Perhaps I am doing something
wrong in my sequence of code?
Here is the declaration for PaymentTxn :
-
public class PaymentTxn implements PaymentTxnInterface {
private int paymentTxnID;
// some other fields
private int customerID;
private CustomerInterface issuingCustomer;
private int bankID;
private BankInterface bank;
public void setIssuingCustomer(CustomerInterface customer) {
this.issuingCustomer = customer;
}
--
Here is the code which creates the paymentTxn and attempts to
insert it
--
PaymentTxn paymentTxn = new PaymentTxn();
...
CustomerInterface customer = payer.getCustomer();
System.out.println(customer id is + customer.getID());
paymentTxn.setIssuingCustomer(customer);
---
and the printout when this segment of code is run :
customer id is 1
801 ERROR [ExecuteThread: '13' for queue: 'default']
accesslayer.JdbcAccessIm
l - SQLException during the execution of the insert (for a
com.mobius.activebil
.persistentobjects.PaymentTxn): INSERT statement conflicted with
COLUMN FOREIGN
KEY constraint 'FK_PaymentTxn_Customer'. The conflict occurred in
database 'Act
veBill', table 'Customer', column 'customerID'.
com.jnetdirect.jsql.w: INSERT statement conflicted with COLUMN
FOREIGN KEY cons
raint 'FK_PaymentTxn_Customer'. The conflict occurred in database
'ActiveBill',
table 'Customer', column 'customerID'.
---
When I look at the generated SQL, I can see the error immediately - the
INSERT statement contains a value of 0 for customerID, even though the
correct customerID (as verified by the printout) is 1.
---
INSERT INTO PaymentTxn
(paymentTxnID,transactionNumber,amount,status,dateStatusChanged,payDate,conf
irmationNumber,bankVoidCode,bankVoidDesc,isPostedToICMS,customerID,bankID,pa
yerID)
VALUES ( '1', '5', '300.35', 'completed', '', '2003-08-12 11:33:00.0',
'4566', 'xx', '', 'true', '0', '1', '1' )
(The customerID value is third from the end)
What is going on here? Has anyone else encountered this kind of problem?
For reference, here are the entries from database_user.xml for the two
classes.
---
!-- Definitions for PaymentTxn table --
class-descriptor
class=com.mobius.activebill.persistentobjects.PaymentTxn
table=PaymentTxn
field-descriptor
name=paymentTxnID
column=paymentTxnID
jdbc-type=INTEGER
primarykey=true
autoincrement=true
/
field-descriptor
name=transactionNumber
column=transactionNumber
jdbc-type=VARCHAR
/
field-descriptor
name=amount
column=amount
jdbc-type=DOUBLE
/
field-descriptor
name=status
column=status
jdbc-type=VARCHAR
/
field-descriptor
name=dateStatusChanged
column=dateStatusChanged
jdbc-type=TIMESTAMP
/
field-descriptor
name=payDate
column=payDate
jdbc-type=TIMESTAMP
/
field-descriptor
name=confirmationNumber
column=confirmationNumber
jdbc-type=VARCHAR
/
field-descriptor
name=bankVoidCode
column=bankVoidCode
jdbc-type=VARCHAR
/
field-descriptor
name=bankVoidDesc
column=bankVoidDesc
jdbc-type=VARCHAR
/
field-descriptor
name=isPostedToICMS
column=isPostedToICMS
jdbc-type=BIT
/
field-descriptor
name=customerID
column=customerID
jdbc-type=INTEGER
/
reference-descriptor
name=issuingCustomer
class-ref=com.mobius.activebill.persistentobjects.Customer
proxy=true
foreignkey field-ref=customerID/
/reference-descriptor
field-descriptor
name=bankID
column=bankID
RE: [FAQ] Re: optimistic locking question
OK, thanks! You know, you could just take what you have written right here, and place that in the documentation. Just a simple quick description of what one has to do, all in one place, is enough for most people. thanks again, Bonnie MacKellar -Original Message- From: Thomas Mahler To: OJB Users List Sent: 6/5/03 2:36 PM Subject: [FAQ] Re: optimistic locking question Hi Bonnie, Bonnie MacKellar wrote: Forgive me, I know this is a really basic question, but... I just finished reading how to set up optimistic locking. I gather that I need to set this explicitly for each class, and that each table needs to have a dedicated column for this purpose (timestamp or integer). Is this correct? correct. It's very simple: 1. you need a dedicated column of type INTEGER or TIMESTAMP 2. you need a (possibly private) attribute in your java class corresponding to the column. 3. in repository.xml you need a field-descriptor for this attribute. this field-descriptor must specify locking=true Is there anything written on optimistic locking besides the info found in http://db.apache.org/ojb/repository.html#field-descriptor? Not yet. It's on my to do list. But it' thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
optimistic locking question
Forgive me, I know this is a really basic question, but... I just finished reading how to set up optimistic locking. I gather that I need to set this explicitly for each class, and that each table needs to have a dedicated column for this purpose (timestamp or integer). Is this correct? Is there anything written on optimistic locking besides the info found in http://db.apache.org/ojb/repository.html#field-descriptor? thanks, Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
tools for coding mappings
I currently handcode my repository_user.xml file, and am having enormous difficulties. I find it is incredibly easy to make typos and many of these typos are incredibly difficult to find. There has got to be a better way. What are you guys using for this purpose? Are there any good tools out there for writing xml files? And does anybody have a good method for making sure that the repository_user names, Java field names, and database field names all match up. I have spent all day on these sorts of bugs, with several fairly large tables. I am ripping my hair out!' Bonnie MacKellar software engineer Mobius Management Systems, Inc. [EMAIL PROTECTED]
RE: repository.xml question
Hmph. I tried that already, and it did not work. Maybe I will try copying your exact xml code below into mine, in case there is a lurking type in my code. thanks a million, Bonnie MacKellar -Original Message- From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:59 AM To: OJB Users List Subject: RE: repository.xml question Here's my repository.xml: ?xml version=1.0 encoding=UTF-8? !-- This is a sample metadata repository for the ObJectBridge System. Use this file as a template for building your own mappings-- !-- defining entities for include-files -- !DOCTYPE descriptor-repository SYSTEM repository.dtd [ !ENTITY database SYSTEM repository_database.xml !ENTITY internal SYSTEM repository_internal.xml !ENTITY user SYSTEM repository_user.xml ] descriptor-repository version=1.0 isolation-level=read-uncommitted !-- include all used database connections -- database; !-- include ojb internal mappings here -- internal; !-- include user defined mappings here -- user; /descriptor-repository As you can see, I took those lines out completely, as well as the ENTITY entries. -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 9:54 AM To: OJB Users List Subject: RE: repository.xml question Did you comment out the lines in repository.xml which refer to the other ones? I am asking because I tried to do that and am getting xml parser errors. Obviously I am doing something very wrong, but a comparison between the original repository.xml and the one I modified is turning up nothing that I can see. thanks, Bonnie MacKellar -Original Message- From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:50 AM To: OJB Users List Subject: RE: repository.xml question Don't know about Weblogic, but I am running fine with only the one's you mentioned plus repository_internal.xml. -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: repository.xml question Which of the files in the repository.xml hierarchy do I really need if I am using OJB in a servlet based app under Weblogic? I know I need repository.xml, repository_database.xml, and repository_user.xml. How about repository_junit.xml, repository_ejb.xml, repository_internal.xml, and repository_jdo.xml? If I do need them, are there any caveats on how they need to be set up? thanks, Bonnie MacKellar - 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]
RE: repository.xml question
No, unfortunately. thanks! -Original Message- From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:37 AM To: OJB Users List Subject: RE: repository.xml question Does sound like a typo to me... Did my repository.xml help? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:31 AM To: OJB Users List Subject: RE: repository.xml question It is a parse error of this form. java.lang.ExceptionInInitializerError: org.xml.sax.SAXParseException: The conten t of elements must consist of well-formed character data or markup. I notice that I get the same error when I try to verify using an xml plugin for Eclipse. -Original Message- From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:13 AM To: OJB Users List Subject: RE: repository.xml question What sort of parser errors, BTW? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:10 AM To: OJB Users List Subject: RE: repository.xml question Hmph. I tried that already, and it did not work. Maybe I will try copying your exact xml code below into mine, in case there is a lurking type in my code. thanks a million, Bonnie MacKellar -Original Message- From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:59 AM To: OJB Users List Subject: RE: repository.xml question Here's my repository.xml: ?xml version=1.0 encoding=UTF-8? !-- This is a sample metadata repository for the ObJectBridge System. Use this file as a template for building your own mappings-- !-- defining entities for include-files -- !DOCTYPE descriptor-repository SYSTEM repository.dtd [ !ENTITY database SYSTEM repository_database.xml !ENTITY internal SYSTEM repository_internal.xml !ENTITY user SYSTEM repository_user.xml ] descriptor-repository version=1.0 isolation-level=read-uncommitted !-- include all used database connections -- database; !-- include ojb internal mappings here -- internal; !-- include user defined mappings here -- user; /descriptor-repository As you can see, I took those lines out completely, as well as the ENTITY entries. -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 9:54 AM To: OJB Users List Subject: RE: repository.xml question Did you comment out the lines in repository.xml which refer to the other ones? I am asking because I tried to do that and am getting xml parser errors. Obviously I am doing something very wrong, but a comparison between the original repository.xml and the one I modified is turning up nothing that I can see. thanks, Bonnie MacKellar -Original Message- From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 10:50 AM To: OJB Users List Subject: RE: repository.xml question Don't know about Weblogic, but I am running fine with only the one's you mentioned plus repository_internal.xml. -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Thursday, April 03, 2003 4:12 PM To: [EMAIL PROTECTED] Subject: repository.xml question Which of the files in the repository.xml hierarchy do I really need if I am using OJB in a servlet based app under Weblogic? I know I need repository.xml, repository_database.xml, and repository_user.xml. How about repository_junit.xml, repository_ejb.xml, repository_internal.xml, and repository_jdo.xml? If I do need them, are there any caveats on how they need to be set up? thanks, Bonnie MacKellar - 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] - 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]
repository.xml question
Which of the files in the repository.xml hierarchy do I really need if I am using OJB in a servlet based app under Weblogic? I know I need repository.xml, repository_database.xml, and repository_user.xml. How about repository_junit.xml, repository_ejb.xml, repository_internal.xml, and repository_jdo.xml? If I do need them, are there any caveats on how they need to be set up? thanks, Bonnie MacKellar
RE: regression test errors
Yes, but if I can't get this tool running in our environment (Weblogic, MSSQL, JTurbo), it won't help us at all. We had ruled out Castor because we had not heard great things about it. I am not familiar with Hibernate or Cayenne. I gravitated towards OJB because it looked a lot like the design for the persistence layer that I had already come up with (we all read the same papers I guess) and because I had heard good buzz about it on other bulletin boards. We evaluated TopLink about 2 years ago and decided against it. I don't know if things have changed in the meantime. thanks, Bonnie -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Saturday, March 29, 2003 7:24 AM To: OJB Users List; Bonnie MacKellar Subject: Re: regression test errors Hi Bonnie, - Original Message - From: Bonnie MacKellar [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Friday, March 28, 2003 7:24 PM Subject: RE: regression test errors I was not at Mobius before 1999, so I really would not know... Yes, this is for an important project and I am not feeling very good about this. The alternatives though, are to buy something or do it ourselves. Our company tends to be of the do it yourself mentality. Since what we need is exactly what OJB provides, it seems silly to replicate it. On the other hand, it is often easier to deal with bugs in your own code then with bugs in someone else's code. I think this is the wrong way, because to implement your own layer you have to write thousands of LOC's and your 'own code project' will lead into the same problems. Use open source, if you got problems browse the sources, patch it or change it by your own. If you think OJB is not comply with your requirements try one of the other powerful open source persistence layer like Hibernate (very well documented), Castor, Cayenne. But keep in mind, none of these layer (including OJB) is 'bug-free' ;-) (and none of the commercial) I would feel a lot better about this if the mail archives worked. My usual approach with this kind of system is to really sift through user archives, looking for similar experiences. Sorry for the mail archive hassle, hope the apache admins will solve the problem soon. Try to use http://www.mail-archive.com/ojb-user%40db.apache.org/ to browse the archive. or the older archive http://www.mail-archive.com/ojb-user%40jakarta.apache.org/ regards, Armin Bonnie -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 1:19 PM To: OJB Users List Subject: RE: regression test errors Bonnie, I'm responding to a note you sent to the OJB mailing list. Is Mobius based in the NYC area? I knew a guy named Howard Deiner who worked at a company named Mobius. His tenure would have been prior to 1999. Just curious. Also curious - will the system you'll be installing OJB into be a large production application? I've been getting OJB up and running for a smaller production project, and I'm nervous about it. I see all the problems on the mailing list and sketchy documentation and wonder what I'm getting myself into. JMHO, of course. Are you feeling the same way? Thanks - MOD --- Bonnie MacKellar [EMAIL PROTECTED] wrote: Thanks for the advice. This parameter is set in C:\db-ojb-1.0.rc1\target\test\ojb\repository_database.xml, right? Do I need to change anything else to modify this behavior? I'm still trying to feel my way around this system. Basically, I have about a week to make a recommendation on using it, in a large project. Ease of use is an important consideration, especially to the powers-that-be who are managing this project. Bonnie -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 6:42 PM To: OJB Users List Subject: Re: regression test errors Seems a problem with the used sequence manager (SequenceManagerHighLowImpl). Try to run the test cases with SequenceManagerInMemoryImpl Do you get the same results? __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: regression test errors
I am coming to this from a slightly different place, since I have already built a simple persistence layer for our products. I have been using JDBC for years. We moved beyond the embed the SQL in the code stage about 2 years ago. Our problem is this : my existing persistence layer needs to be upgraded if it is to be used in our next product. It was SIMPLE, after all. But management likes the layer as is and does not want us to change it. Thus, I either need to rewrite the layer with the needed enhancements, or use something like OJB. We have a tight deadline, and need to decide this week. The advantage of doing it ourselves is that it will work in our environment (Weblogic, JDBC, MSSQL). The only other DBMS that we support is Oracle, and I know how to design a layer that works with both MSSQL and Oracle. The disadvantage of course is that it takes time to build a persistence layer well. Management here tends to be leery about taking on third party software. Bonnie MacKellar -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: Saturday, March 29, 2003 12:25 PM To: OJB Users List; [EMAIL PROTECTED] Subject: Re: regression test errors Thanks to both Thomas and Armin for their replies on this thread. Speaking for myself, I'm nervous about using OJB on my current project, too, but I don't think the source is entirely OJB. A big part of it is fear of what I DON'T know. I very much liked the idea of using a tool, developed by folks more expert than me. I know enought about JDBC to be able to do CRUD operations and simple transactions, but the idea of having a layer to abstract all that out of business objects was appealing. I heard Martin Fowler talk a few months ago. He mentioned using JAXOR as an O/R mapping tool. When I looked into it, I found NO documentation whatsoever. Google quickly turned up OJB as an alternative. I liked it right away, because it had more documentation than JAXOR, it the cachet of being a Jakarta project, and the stuff that I did actually worked. Now I've got a tree of four tables linked with m:n associations, all working in JUnit tests. All that's well and good, but now I'm nervous about that learning curve and what I'm ignorant of. I've done everything with the PersistenceBroker API because it was easy to follow in the docs. But now I'm thinking that I should really be doing all of this using ODMG API instead. More learning, with a deadline approaching. Here's a fundamental question: RDBMS developers have put a lot of effort into maintaining referential integrity, managing transactions, etc. It seems to me that OJB is taking over a lot of that stuff. When I created my tables, I didn't add foreign key constraints. I left all that to OJB. The ODMG API will handle true transactions and object/row locking. But what if OJB isn't the only path into the database? A DBA might balk at leaving all those things that the RDBMS would handle to OJB. Is it possible still leave foreign key constraints in the database so others could use them without OJB? My compliments to Thomas, Armin, and the team that created OJB. None of this fear is a reflection on your excellent work. It has more to do with the fact that this is still a version 1.0 release candidate and my own ignorance. Sincerely, MOD --- Thomas Mahler [EMAIL PROTECTED] wrote: Hi Bonnie, Bonnie MacKellar wrote: I was not at Mobius before 1999, so I really would not know... Yes, this is for an important project and I am not feeling very good about this. The alternatives though, are to buy something or do it ourselves. Our company tends to be of the do it yourself mentality. Since what we need is exactly what OJB provides, it seems silly to replicate it. On the other hand, it is often easier to deal with bugs in your own code then with bugs in someone else's code. OJB is 3 years of heavy designed code by experts in the O/R area. We have a complete regression testsuite that covers each and every aspect of the system. Do it yourself is definitely a bad idea in this area. If you don't trust us better use a commercial tool like TopLink. OJB is in production use in large projects for 2 years now. My company is using OJB in several large and mission critical software projects since a year now. I would feel a lot better about this if the mail archives worked. My usual approach with this kind of system is to really sift through user archives, looking for similar experiences. I admit this is really annoying. But this is clearly not an OJB problem, but an infrastructure problem with some Apache server. For the time being use archive mirrors at GMANE or at http://www.mail-archive.com/ojb-user%40db.apache.org/ cheers, Thomas Bonnie -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 1:19 PM To: OJB Users List Subject: RE: regression test
RE: MSSQL server - error in ojbtest-schema.xml
Thanks for this post. I was also getting this today (using JTurbo).
Bonnie MacKellar
-Original Message-
From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:05 PM
To: OJB Users List
Subject: MSSQL server - error in ojbtest-schema.xml
Don't know if I should submit a bug report on this or not, but when I tried
to run the prepare-testdb target using MSSQL server 2000 (MS's JDBC Driver),
I would get the following error:
[torque-insert-sql] Executing file:
C:\java\utils\db-ojb-1.0.rc2\target\src\sql\ojbtest-schema.sql
[torque-insert-sql] Failed to execute:
/* -- */
[torque-insert-sql] /* REF_REPOSITORY_FK
*/ /* --
*/ IF EXISTS (SELECT 1
( ... )
[torque-insert-sql] java.sql.SQLException: [Microsoft][SQLServer 2000 Driver
for JDBC][SQLServer]Cannot define PRIMARY KEY constraint on nullable column
in table 'REF_REPOSITORY_FK'.
This was fixed by changing the REF_REPOSITORY_FK table description in
${OJB_HOME}\src\schema\ojbtest-schema.xml to make the required fields not
null:
table name=REF_REPOSITORY_FK
column name=REP_ID required=true primaryKey=true
type=INTEGER/
column name=REF_FK required=true type=INTEGER
primaryKey=true/
column name=REFA_FK required=true type=INTEGER
primaryKey=true/
column name=REFB_FK required=true type=INTEGER
primaryKey=true/
column name=NAME type=VARCHAR size=100/
/table
The tables now build correctly, though I am still tracking down some failed
JUnit tests. Hope this helps somebody...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: MSSQL server - error in ojbtest-schema.xml
I tested on Friday with the rc1 build, using JSQLConnect,
and got 0 failures, 1 error, which I was told was not important.
Today, testing with the rc2 build, and with the columns modifed
to be NOT NULL as specified earlier, I get 0 failures, 4 errors.
I have no clue if these are important or not.
Bonnie MacKellar
-Original Message-
From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 5:01 PM
To: OJB Users List
Subject: RE: MSSQL server - error in ojbtest-schema.xml
Some issues with the JSQLConnect driver:
1. Due to network restrictions, I suppose, I was getting 403 errors using
the ant task to download the driver. I grabbed it manually without incident,
and commented out the ant call.
2. I am actually getting *more* JUnit failures/errors with this driver,
though I concede it may be due to the changes I mentioned below in the
ojbtest-schema.xml?
3. With the money the PHB's are already throwing at MS licensing, I am loath
to try and work another ($4000+ for us, if I read their pricing correctly)
purchase into the budget...
-Original Message-
From: Matthew Baird [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:25 PM
To: OJB Users List
Subject: RE: MSSQL server - error in ojbtest-schema.xml
I don't have any issues with MSSQL, but the driver always makes a
difference. When people ask me I recommend the JSQLConnect #1 and Opta2000
#2. Bother are great drivers.
-Original Message-
From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 1:25 PM
To: OJB Users List
Subject: RE: MSSQL server - error in ojbtest-schema.xml
I'll give it a shot. Truth to tell, *I* wouldn't use MSSQL server at all,
but this is a port of an app we inherited, so we're kinda stuck... :(
-Original Message-
From: Matthew Baird [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:20 PM
To: OJB Users List
Subject: RE: MSSQL server - error in ojbtest-schema.xml
if you are worried about using OJB, I'd be more worried about using the MS
Driver.
Switch over and use the JSQLConnect profile and the build will automatically
download the jsqlconnect driver which is much better.
-Original Message-
From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 1:20 PM
To: OJB Users List
Subject: RE: MSSQL server - error in ojbtest-schema.xml
Glad I could help. I can sympathize with your trepidation about using OJB in
a large project. Seems I've been taking one step forward and two steps back
for the last few days. I like what it is and what it does, though, and I
can't see hacking a persistence service for the projects I have lined up
would be very cost-effective...
As for those JUnit errors I mentioned before, anyone getting anything like
this (from tests-broker.txt):
[org.apache.ojb.broker.accesslayer.JdbcAccessImpl] ERROR: SQLException
during the execution of the query (SELECT count(A0.*) FROM Artikel A0 WHERE
A0.Kategorie_Nr = ? ) (for a org.apache.ojb.broker.Article):
[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect
syntax near '*'.
[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect
syntax near '*'.
I hacked the test a bit so I could see the query that bombed
(pre-preparation), but it doesn't look like it should fail to me. I'm down
to my last three errors (broker tests) and one failure (ODMG tests) and
would like to start testing with real data in my application environment.
-Original Message-
From: Bonnie MacKellar [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:09 PM
To: OJB Users List
Subject: RE: MSSQL server - error in ojbtest-schema.xml
Thanks for this post. I was also getting this today (using JTurbo).
Bonnie MacKellar
-Original Message-
From: BURT, RANDALL (CONTRACTOR) [mailto:[EMAIL PROTECTED]
Sent: Monday, March 31, 2003 3:05 PM
To: OJB Users List
Subject: MSSQL server - error in ojbtest-schema.xml
Don't know if I should submit a bug report on this or not, but when I tried
to run the prepare-testdb target using MSSQL server 2000 (MS's JDBC Driver),
I would get the following error:
[torque-insert-sql] Executing file:
C:\java\utils\db-ojb-1.0.rc2\target\src\sql\ojbtest-schema.sql
[torque-insert-sql] Failed to execute:
/* -- */
[torque-insert-sql] /* REF_REPOSITORY_FK
*/ /* --
*/ IF EXISTS (SELECT 1
( ... )
[torque-insert-sql] java.sql.SQLException: [Microsoft][SQLServer 2000 Driver
for JDBC][SQLServer]Cannot define PRIMARY KEY constraint on nullable column
in table 'REF_REPOSITORY_FK'.
This was fixed by changing the REF_REPOSITORY_FK table description in
${OJB_HOME}\src\schema\ojbtest-schema.xml to make the required fields not
null:
table name=REF_REPOSITORY_FK
column name=REP_ID required=true primaryKey=true
type=INTEGER/
column name=REF_FK
RE: regression test errors
I am off right now to a meeting to discuss my results with OJB. I will feel out the possibility of using JSQLConnect. Do you know, can it work with Weblogic? Our current environment is a JSP frontend, with Weblogic as an app server (no EJBs at all, no CMP), and JTurbo as the JDBC driver. If I can just substitute JSQLconnect in there, it might be OK. TopLink's price tag was indirectly a problem. We will pay that much for a system, but it has to go up to a VP who is chronically allergic to third party development systems. We may be more successful bringing OJB in because it does not need the same level of review, due to its, um, low price tag. Bonnie -Original Message- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 12:55 PM To: OJB Users List Subject: Re: regression test errors Hi Bonnie, Bonnie MacKellar wrote: Yes, but if I can't get this tool running in our environment (Weblogic, MSSQL, JTurbo), it won't help us at all. There are happy OJB + WebLogic users. Several of them migrated from WebLogic CMP to OJB. There are also happy OJB + MSSQL users. I don't know of any users using the JTurbo driver. We have excellent support for the JSQLConnect driver from http://www.j-netdirect.com/. I know that there are large differences in the available SQLServer JDBC drivers. And I have no direct knowledge if there are any problems with JTurbo +OJB. If there are such Problems it will be possible to work around it. OJB uses a Platform interface to abtract from the underlying jdbc driver and database. All platform specifics can be encapsulated in a PlatFormJturboImpl if required. We have done this sucessfully for a large range of databases and JDBC drivers. Including such extravagant platforms like Tandem Nonstop SQL databases! We had ruled out Castor because we had not heard great things about it. There seems to be no more active development on Castor. I am not familiar with Hibernate or Cayenne. I gravitated towards OJB because it looked a lot like the design for the persistence layer that I had already come up with (we all read the same papers I guess) I agree. O/R is not rocket science. It is a well known and cartographed domain. So a good O/R implementation will make use of all the known best practices and patterns of that domain. I sometimes say OJB has a pattern driven design, to reflect this best practise approach. and because I had heard good buzz about it on other bulletin boards. We evaluated TopLink about 2 years ago and decided against it. why? I have made good experiences with TopLink. The only problem we had was the price tag. But afaik this has changed a lot since there are opensource alternatives available. cheers, Thomas I don't know if things have changed in the meantime. thanks, Bonnie -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Saturday, March 29, 2003 7:24 AM To: OJB Users List; Bonnie MacKellar Subject: Re: regression test errors Hi Bonnie, - Original Message - From: Bonnie MacKellar [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Friday, March 28, 2003 7:24 PM Subject: RE: regression test errors I was not at Mobius before 1999, so I really would not know... Yes, this is for an important project and I am not feeling very good about this. The alternatives though, are to buy something or do it ourselves. Our company tends to be of the do it yourself mentality. Since what we need is exactly what OJB provides, it seems silly to replicate it. On the other hand, it is often easier to deal with bugs in your own code then with bugs in someone else's code. I think this is the wrong way, because to implement your own layer you have to write thousands of LOC's and your 'own code project' will lead into the same problems. Use open source, if you got problems browse the sources, patch it or change it by your own. If you think OJB is not comply with your requirements try one of the other powerful open source persistence layer like Hibernate (very well documented), Castor, Cayenne. But keep in mind, none of these layer (including OJB) is 'bug-free' ;-) (and none of the commercial) I would feel a lot better about this if the mail archives worked. My usual approach with this kind of system is to really sift through user archives, looking for similar experiences. Sorry for the mail archive hassle, hope the apache admins will solve the problem soon. Try to use http://www.mail-archive.com/ojb-user%40db.apache.org/ to browse the archive. or the older archive http://www.mail-archive.com/ojb-user%40jakarta.apache.org/ regards, Armin Bonnie -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 1:19 PM To: OJB Users List Subject: RE: regression test errors Bonnie, I'm responding to a note you sent to the OJB mailing list. Is Mobius based in the NYC area? I
RE: regression test errors
I was not at Mobius before 1999, so I really would not know... Yes, this is for an important project and I am not feeling very good about this. The alternatives though, are to buy something or do it ourselves. Our company tends to be of the do it yourself mentality. Since what we need is exactly what OJB provides, it seems silly to replicate it. On the other hand, it is often easier to deal with bugs in your own code then with bugs in someone else's code. I would feel a lot better about this if the mail archives worked. My usual approach with this kind of system is to really sift through user archives, looking for similar experiences. Bonnie -Original Message- From: Michael Duffy [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 1:19 PM To: OJB Users List Subject: RE: regression test errors Bonnie, I'm responding to a note you sent to the OJB mailing list. Is Mobius based in the NYC area? I knew a guy named Howard Deiner who worked at a company named Mobius. His tenure would have been prior to 1999. Just curious. Also curious - will the system you'll be installing OJB into be a large production application? I've been getting OJB up and running for a smaller production project, and I'm nervous about it. I see all the problems on the mailing list and sketchy documentation and wonder what I'm getting myself into. JMHO, of course. Are you feeling the same way? Thanks - MOD --- Bonnie MacKellar [EMAIL PROTECTED] wrote: Thanks for the advice. This parameter is set in C:\db-ojb-1.0.rc1\target\test\ojb\repository_database.xml, right? Do I need to change anything else to modify this behavior? I'm still trying to feel my way around this system. Basically, I have about a week to make a recommendation on using it, in a large project. Ease of use is an important consideration, especially to the powers-that-be who are managing this project. Bonnie -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 6:42 PM To: OJB Users List Subject: Re: regression test errors Seems a problem with the used sequence manager (SequenceManagerHighLowImpl). Try to run the test cases with SequenceManagerInMemoryImpl Do you get the same results? __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: setup and list archive problems
OK, after some amount of experimentation, I seem to have honed in on the problem : I can build with the JSDK1.4, but not with the JSDK1.3 In 1.3, the rt.jar does not include javax.sql.DataSource, but it does in 1.4 Now of course, the regression tests are failing. The strange thing is, I get a different number of errors each time I run the regression tests. thanks, Bonnie MacKellar -Original Message- From: Mauricio CASTRO [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 3:39 PM To: OJB Users List Subject: Re: setup and list archive problems Look at the biuld.xml file. There you will find many target tags Read the comentaries for each tag and then try make target_tag_name. There is one which make junit without the sources. I also recently posted: The URL bellow shows which are the exact dependencies. http://db.apache.org/torque/dependencies.html The question of whether computers can think is like the question of whether submarines can swim., Edsger Wybe Dijkstra (1930-2002). - Original Message - From: Alexandre Touret [EMAIL PROTECTED] To: OJB Users List [EMAIL PROTECTED] Sent: Thursday, March 20, 2003 3:08 AM Subject: Re: Instalation problems. dump-testdb. You must add to your classpath the librairies included with torque (http://db.apache.org/torque) Alexandre Touret Mauricio CASTRO wrote: Hi. After executing bin\build.bat dump-testdb I get the following error: BUILD FAILED java.lang.NoClassDefFoundError: com/workingdogs/village/DataSet I need to download the village jar? What else do I need to download? Thank you in advance. Mauricio. The question of whether computers can think is like the question of whether submarines can swim., Edsger Wybe Dijkstra (1930-2002). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- __ Alexandre Touret CGBI 69 Boulevard Galliéni 92130 Issy les Moulineaux tel.: 01/55/95/53/95Poste: 5395 mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The question of whether computers can think is like the question of whether submarines can swim., Edsger Wybe Dijkstra (1930-2002). - Original Message - From: Shane Mingins [EMAIL PROTECTED] To: 'OJB Users List' [EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:59 PM Subject: RE: setup and list archive problems Did you read the sections under User Documentation? I am new to OJB and working in a Windows 2000 environment but have it working against an AS400 database. I also had 0.9.8 working against MySQL. So from memory... I downloaded and extracted both the source and binary archive files to the same directory. I edited the platform profile as per http://db.apache.org/ojb/platforms.html I had JAVA_HOME already set. I chucked my jdbc driver jar file into the jakarta-ojb-xxx/lib directory. I ran bin\build junit under Win32. And then I followed the instructions for tutorial 1. Not sure if any of that helps? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 March 2003 9:43 a.m. To: OJB Users List Subject: RE: setup and list archive problems Actually, I tried that, but ran into problems building the source. Since there is very little documentation, I decided I was silly for trying to build the source when there is a binary distribution. OK, I will ask about building the source distribution then. When I run build junit with the source distribution, it is unable to resolve DataSource. Now, I have JAVA_HOME set to point to my jdk1.3 base directory, and it seems to be found. I have my JDBC driver (JTurbo.jar) in my classpath. So what am I missing? Again, if there is documentation someplace, I would be happy to read it and not waste people's time with basic questions. Bonnie -Original Message- From: Shane Mingins [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:37 PM To: 'OJB Users List' Subject: RE: setup and list archive problems I had that problem and so I downloaded and extracted the source as well and it worked. I think I saw somewhere where it is suggested to do that. Yes, the mailing list archive is broken. I do not who/when it is to be fixed? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 March 2003 9:26 a.m. To: [EMAIL PROTECTED] Subject: setup and list archive problems Hi, I am new to OJB, and evaluating it for a new project we are undertaking. I am sure my questions are old hat for you guys, but I cannot seem to make the mailing list archives work for me, so I cannot search for previous posts on this topic. I have db-ojb-1.0.rc1 set up from the binary distribution
regression test errors
OK, now that I have a build, how do I go about understanding and fixing errors in the regressions tests? My environment : built with JSDK1.4.0_03 DBMS is MSSqlServer2000 JDBC driver is JTurbo 3.0.2 JDBC 2.1 Driver I get several errors in the broker tests : Testsuite: org.apache.ojb.broker.AllTests Tests run: 187, Failures: 2, Errors: 10, Time elapsed: 50.583 sec Most of these errors seem to be socket failures JTurbo 3.0.2 JDBC 2.1 Driver]: Communication Link Failure. Socket Closed [org.apache.ojb.broker.util.sequence.SequenceManagerHelper] WARN: Cannot lookup max value from table SM_TAB_BB for column SM_ID, PB was [EMAIL PROTECTED], using jdbc-descriptor [EMAIL PROTECTED] or connection problems Error getting Connection from DriverManager with url (jdbc:JTurbo://W2KBMACKELL/ActiveBill) and driver (com.newatlanta.jturbo.driver.Driver): Login failed for user '!!TestCase: This should fail!!'. Used ConnectionManager instance could not obtain a connection: Could not borrow connection from pool - org.apache.ojb.broker.metadata.JdbcConnectionDescriptor: [EMAIL PROTECTED] Now, I have successfully used JTurbo and this DBMS in the past to do connection pooling under Weblogic, so I don't think there is a DBMS configuration problem. What is the best way to attack this sort of problem? What files should I be looking at? thanks, Bonnie MacKellar [EMAIL PROTECTED]
RE: setup and list archive problems
I read the Deployment section under User Documentation. But mainly,it covers steps that I have not gotten to yet. I did exactly the same steps as you. But I get an unresolved symbol error for javax.sql.DataSource. My jdbc driver is JTurbo. I wonder if anyone else has gotten ojb working with that driver? The thing is, I am evaluating this system for use in a large product. And stability and ease of use are two things we are looking for. thanks, Bonnie MacKellar -Original Message- From: Shane Mingins To: 'OJB Users List' Sent: 3/24/03 4:59 PM Subject: RE: setup and list archive problems Did you read the sections under User Documentation? I am new to OJB and working in a Windows 2000 environment but have it working against an AS400 database. I also had 0.9.8 working against MySQL. So from memory... I downloaded and extracted both the source and binary archive files to the same directory. I edited the platform profile as per http://db.apache.org/ojb/platforms.html I had JAVA_HOME already set. I chucked my jdbc driver jar file into the jakarta-ojb-xxx/lib directory. I ran bin\build junit under Win32. And then I followed the instructions for tutorial 1. Not sure if any of that helps? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 March 2003 9:43 a.m. To: OJB Users List Subject: RE: setup and list archive problems Actually, I tried that, but ran into problems building the source. Since there is very little documentation, I decided I was silly for trying to build the source when there is a binary distribution. OK, I will ask about building the source distribution then. When I run build junit with the source distribution, it is unable to resolve DataSource. Now, I have JAVA_HOME set to point to my jdk1.3 base directory, and it seems to be found. I have my JDBC driver (JTurbo.jar) in my classpath. So what am I missing? Again, if there is documentation someplace, I would be happy to read it and not waste people's time with basic questions. Bonnie -Original Message- From: Shane Mingins [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:37 PM To: 'OJB Users List' Subject: RE: setup and list archive problems I had that problem and so I downloaded and extracted the source as well and it worked. I think I saw somewhere where it is suggested to do that. Yes, the mailing list archive is broken. I do not who/when it is to be fixed? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 March 2003 9:26 a.m. To: [EMAIL PROTECTED] Subject: setup and list archive problems Hi, I am new to OJB, and evaluating it for a new project we are undertaking. I am sure my questions are old hat for you guys, but I cannot seem to make the mailing list archives work for me, so I cannot search for previous posts on this topic. I have db-ojb-1.0.rc1 set up from the binary distribution and am trying to follow the Quick Start guide. I am encountering NUMEROUS problems. I wonder if there is a more detailed guide than the Quick Start, or an installation FAQ? When I try to run build junit, I get an error message to the effect C:\db-ojb-1.0.rc1\src\java not found I would not have expected that directory to be present since this is a binary distribution. Obviously, I am doing something wrong, but what? thanks, Bonnie MacKellar [EMAIL PROTECTED] - 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]
RE: setup and list archive problems
Actually, I tried that, but ran into problems building the source. Since there is very little documentation, I decided I was silly for trying to build the source when there is a binary distribution. OK, I will ask about building the source distribution then. When I run build junit with the source distribution, it is unable to resolve DataSource. Now, I have JAVA_HOME set to point to my jdk1.3 base directory, and it seems to be found. I have my JDBC driver (JTurbo.jar) in my classpath. So what am I missing? Again, if there is documentation someplace, I would be happy to read it and not waste people's time with basic questions. Bonnie -Original Message- From: Shane Mingins [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:37 PM To: 'OJB Users List' Subject: RE: setup and list archive problems I had that problem and so I downloaded and extracted the source as well and it worked. I think I saw somewhere where it is suggested to do that. Yes, the mailing list archive is broken. I do not who/when it is to be fixed? -Original Message- From: Bonnie MacKellar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 March 2003 9:26 a.m. To: [EMAIL PROTECTED] Subject: setup and list archive problems Hi, I am new to OJB, and evaluating it for a new project we are undertaking. I am sure my questions are old hat for you guys, but I cannot seem to make the mailing list archives work for me, so I cannot search for previous posts on this topic. I have db-ojb-1.0.rc1 set up from the binary distribution and am trying to follow the Quick Start guide. I am encountering NUMEROUS problems. I wonder if there is a more detailed guide than the Quick Start, or an installation FAQ? When I try to run build junit, I get an error message to the effect C:\db-ojb-1.0.rc1\src\java not found I would not have expected that directory to be present since this is a binary distribution. Obviously, I am doing something wrong, but what? thanks, Bonnie MacKellar [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
