Re: automatic failover
Hi Stephen, Stephen Ting wrote: Hi, I think that's make no different than catching PersistenceBrokerException because it is the Subclass of OJBRuntimeException. for me here is a subtle difference, since OJBRuntimeException is a subclass of RuntimeException. so if in one component such an exception is thrown, it will just fall throw your catch clause. I dont know the OJB code that well to know whether an OBJBrokerException can be thrown by the use of the PersistentBroker, but to be on the safe side I would catch OJBRuntimeException. in the end I agree that a PersistentBrokerException should be sufficient according to the javadocs. so I just tried to see if I can reproduce such an exception, but I see which is wrapped in an application exception and passed correctly to the servlet. maybe the message I just posted about old thread: Re: ConnectionFactoryManagedImpl and rollbacks is of any interest for you. hope that helps a bit. best wishes Kristian Whereas, for my case where I uses OJB in session bean, it's throw RemoteException whenever there is communication link breakdown. The PersistenceBrokerExeption catch in session bean was not propagate to the web container. Hopefully, this is correct. Cheers, Stephen -- -- Jentro Technologies GmbH Kristian Meier, Developer -- Rosenheimer Str. 145e 81671 Munich, Germany Tel. +49 89 189 169 80mailto: [EMAIL PROTECTED] Fax. +49 89 189 169 99internet: http://www.jentro.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
old thread: Re: ConnectionFactoryManagedImpl and rollbacks
Hi Armin, I am very sorry to come back to the same topic after such a long time, but we are super bussy to get our thing up and running. we are using the Persistent Broker API in an managed enviroment as jboss or OC4J (oracle application server). using the ojb.org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl from OJB with jboss I see the following log: --- [ejb.ojb.org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] (Thread-10) Rollback was called, do rollback on current connection [EMAIL PROTECTED] [ejb.ojb.org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] (Thread-10) Rollback on the underlying connection failed java.sql.SQLException: You cannot rollback during a managed transaction! at org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.jdbcRollback(LocalManagedConnection.java:478) at org.jboss.resource.adapter.jdbc.local.LocalConnection.rollback(LocalConnection.java:457) at org.apache.ojb.broker.util.WrappedConnection.rollback(Unknown Source) at org.apache.ojb.broker.util.pooling.ByPassConnection.rollback(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.localRollback(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.abortTransaction(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.abortTransaction(Unknown Source) --- if I use an implentation which produces connections with a NOOP-rollback method, than I see only: --- [ejb.ojb.org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] (Thread-11) Rollback was called, do rollback on current connection [EMAIL PROTECTED] 14:00:20,312 INFO [STDOUT] ** we ignore rollback --- when I understand the JDO spec correct, than the transaction borders is done by the embedding enviroment only. so altogether our own implementation works fine on jboss and on OC4J with our connection factory. FYI: OJB really helped us a lot to have an application which deploys easiely on serveral application servers !! hope you find the time for checking it. best wishes Kristian Armin Waibel wrote: > Hi Kristian, > > sorry for the late reply. > In next future I didn't find the time to check > your proposal to make rollback() a noop in > ConnectionFactoryManaged Impl, but sounds > correct. In a managed environment there is no > need (think it's not allowed) to rollback > connection. > What's your experience with the changed Factory? > Which API do you use (odmg, pb)? > > regards, > Armin > > - Original Message - > From: "kristian meier" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Friday, September 12, 2003 5:04 PM > Subject: ConnectionFactoryManagedImpl and rollbacks > > > >>Hello, >> >>we are using OJB on an application server, in the moment JBoss. >>everything works fine until >>there comes an exception and the PersistentBroker gets closed without > > a > >>commit. >> >>in the close()-method the broker does a rollback on the underlying >>connection-object and with >>the ByPassConnection the rollback is then triggered on the underlying >>connection-object. >> >>now my exception is caught by the EJB-container and again a rollback > > is > >>triggered on the current transaction, >>which generates another exception from the EJB-container. >> >>we have seen this behaviour also on WebSphere and on >>SunONE-Applicationserver. >> >>things seemed to be better after we used our own >>ConnectionFactoryManagedImpl where the rollback()-method >>is also no-op. >> >>do I miss something, why the rollback()-method is needed as is in an >>applcation-server-scenario ? >> >>some hints are welcome to understand better what is going on here, > > thank you > >>Kristian >> -- -- Jentro Technologies GmbH Kristian Meier, Developer -- Rosenheimer Str. 145e 81671 Munich, Germany Tel. +49 89 189 169 80mailto: [EMAIL PROTECTED] Fax. +49 89 189 169 99internet: http://www.jentro.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: automatic failover
tandardPipeline$StandardPipelineValveContext.i nvokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:4 80) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:60 1) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processC onnection(Http11Protocol.java:392) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:56 5) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:619) at java.lang.Thread.run(Thread.java:534) ** END NESTED EXCEPTION ** -- -- Jentro Technologies GmbH Kristian Meier, Developer -- Rosenheimer Str. 145e 81671 Munich, Germany Tel. +49 89 189 169 80mailto: [EMAIL PROTECTED] Fax. +49 89 189 169 99internet: http://www.jentro.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ConnectionFactoryManagedImpl and rollbacks
Hello, we are using OJB on an application server, in the moment JBoss. everything works fine until there comes an exception and the PersistentBroker gets closed without a commit. in the close()-method the broker does a rollback on the underlying connection-object and with the ByPassConnection the rollback is then triggered on the underlying connection-object. now my exception is caught by the EJB-container and again a rollback is triggered on the current transaction, which generates another exception from the EJB-container. we have seen this behaviour also on WebSphere and on SunONE-Applicationserver. things seemed to be better after we used our own ConnectionFactoryManagedImpl where the rollback()-method is also no-op. do I miss something, why the rollback()-method is needed as is in an applcation-server-scenario ? some hints are welcome to understand better what is going on here, thank you Kristian -- -- Jentro Kristian Meier, Developer -- Peter-Henlein-Strasse 28, 85540 Haar/Munich, Germany Tel. +49 89 462 385 0 mailto: [EMAIL PROTECTED] Fax +49 89 462 385 28internet: http://www.jentro.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible OJB Bug with Oracle
here is the conversion class I am now using:
public class OracleFieldConversion implements FieldConversion {
public OracleFieldConversion(){
}
// Implementation of
org.apache.ojb.broker.accesslayer.conversions.FieldConversion
/**
* Describe javaToSql method here.
*
* @param object an Object value
* @return an Object value
* @exception ConversionException if an error occurs
*/
public Object javaToSql(Object object) throws ConversionException {
return new Long( object.toString() );
}
/**
* Describe sqlToJava method here.
*
* @param object an Object value
* @return an Object value
* @exception ConversionException if an error occurs
*/
public Object sqlToJava(Object object) throws ConversionException {
if( object == null ) return null;
else return new Integer( object.toString() );
}
}// OracleFieldConversion
Brown, Melonie S. - Contractor wrote:
I did not realize this either. Perhaps a note in the section of the
documentation on datatypes would be helpful for others. :)
Kristian - would you mind posting your FieldConversion code?
Thanks!
Melonie
Original Message
Subject: Re: Possible OJB Bug with Oracle
Date: Thu, 05 Jun 2003 13:35:35 +0200
From: kristian meier <[EMAIL PROTECTED]>
Reply-To: OJB Users List <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.jakarta.ojb.user
References:
<[EMAIL PROTECTED]>
Sorry for my ignorance, I just did not expected any problems while
switching the databases.
with a simple FieldConversion, now all my Integer-fields also work on
Oracle.
that's for help ;-)
with best wishes Kristian
Mahler Thomas wrote:
Hi again,
-Original Message-----
From: kristian meier [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 11:54 AM
To: OJB Users List
Subject: Re: Possible OJB Bug with Oracle
Hi Thomas,
just to understand, if
repository.xml
is wrongly configured it shouldn't work with mysql, hsqldb as
well not oracle.
I don't agree. Oracles datatype NUMBER is something completely different
than the INTEGER type on MySql or Hsqldb!
Oracle NUMBER expects a BigInt on the java side. If you want something
different you definitely need a FielConversion.
cheers,
Thomas
basically the same file (the platform attribute changes
respectivly) works fine for mysql, hsqldb, but
not for oracle !!! all java classes are the same in each
case, and the underlying java class has an int !!
so I would appreciate some further hints !!
with best wishes Kristian
Mahler Thomas wrote:
Hi Kristian,
For me this does not look like a OJB bug, but as a
configuration problem.
If you have a java attribute of type String but have defined
it as INTEGER
in the repository.xml you've got a problem!
If you want to have a String attribute converted into an
Oracle Number
column you should use a FieldConversion but not change the
PlatformOracleImpl.
cheers,
thomas
-
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: Possible OJB Bug with Oracle
Sorry for my ignorance, I just did not expected any problems while
switching the databases.
with a simple FieldConversion, now all my Integer-fields also work on
Oracle.
that's for help ;-)
with best wishes Kristian
Mahler Thomas wrote:
Hi again,
-Original Message-
From: kristian meier [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 11:54 AM
To: OJB Users List
Subject: Re: Possible OJB Bug with Oracle
Hi Thomas,
just to understand, if
repository.xml
is wrongly configured it shouldn't work with mysql, hsqldb as
well not oracle.
I don't agree. Oracles datatype NUMBER is something completely different
than the INTEGER type on MySql or Hsqldb!
Oracle NUMBER expects a BigInt on the java side. If you want something
different you definitely need a FielConversion.
cheers,
Thomas
basically the same file (the platform attribute changes
respectivly) works fine for mysql, hsqldb, but
not for oracle !!! all java classes are the same in each
case, and the underlying java class has an int !!
so I would appreciate some further hints !!
with best wishes Kristian
Mahler Thomas wrote:
Hi Kristian,
For me this does not look like a OJB bug, but as a
configuration problem.
If you have a java attribute of type String but have defined
it as INTEGER
in the repository.xml you've got a problem!
If you want to have a String attribute converted into an
Oracle Number
column you should use a FieldConversion but not change the
PlatformOracleImpl.
cheers,
thomas
-Original Message-
From: kristian meier [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 9:46 AM
To: OJB Users List
Subject: Re: Possible OJB Bug with Oracle
Hello,
when I yesterday switch to oracle I came across the same
exception and I
investigated a bit, and
found an unexpected situation in the PlatformOracleImpl.java
in the setObjectForStatement( ) method the sqlType was
Type.INTEGER
and the value was a String class
both arguments were passed to the PlatformDefaultImpl.java
where they
were passed into the PreparedStatement.
the String class seemed to be already wrong at this place,
but a simple
hack does work fine for me:
*** PlatformOracleImpl.javaSun May 4 14:08:14 2003
---
src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
Thu Jun 5 09:17:58 2003
***
*** 126,131
--- 126,138
ps.setLong(index, ((Integer) value).intValue());
}
+ else if (sqlType == Types.INTEGER && value
instanceof String)
+ {
+ // workaround:
+ ps.setInt(index, Integer.parseInt( (String) value ) );
+ }
else
{
+ this.logger.debug( "using type " + sqlType + " for
class " +
value.getClass().getName()
++ "(" + value + ")" );
super.setObjectForStatement(ps, index, value,
sqlType);
}
maybe this also helps to find the real bug !!!
with best wishes Kristian
Brown, Melonie S. - Contractor wrote:
Has anybody else ran into this? This is a big problem for
us, and I'm
catching a lot of flack since I recommended we use OJB.
It appears that OJB is generating a getCollection query even
though the code
specifies a single object.
I'm not sure where to begin debugging, so any assistance
would be greatly
appreciated.
Original Message
Subject: [RC3] Works with MySql, Fails with
ClassCastException with Oracle
Date: Thu, 29 May 2003 11:41:00 -0400
From: Brown, Melonie S. - Contractor
<[EMAIL PROTECTED]>
Reply-To: OJB Users List <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.jakarta.ojb.user
I have code that works perfectly fine in MySQL but crashes
and dies against
an Oracle database. I'm getting a java.lang.ClassCastException at
GetCollectionByQuery which doesn't make sense since I'm calling
broker.getObjectbyQuery. Also, no SQL statements show in
the spy.log file.
Suggestions would be greatly appreciated.
This is the code:
public static RcioDB retrieveRcio(RcioDB sRcio) throws
DataStoreException
{
PersistenceBroker broker = GetAccess.getPersistenceBroker();
try
{
broker.beginTransaction();
Criteria crit = new Criteria();
crit.addEqualTo(
Constants.RCIO_ID,
String.valueOf(sRcio.getRcio_ID()));
System.out.println("criteria set");
QueryByCriteria query =
QueryFactory.newQuery(RcioDB.class,
crit);
System.out.println("query created");
Object
Re: Possible OJB Bug with Oracle
Hi Thomas,
just to understand, if
repository.xml
is wrongly configured it shouldn't work with mysql, hsqldb as well not oracle.
basically the same file (the platform attribute changes respectivly) works fine for
mysql, hsqldb, but
not for oracle !!! all java classes are the same in each case, and the underlying java
class has an int !!
so I would appreciate some further hints !!
with best wishes Kristian
Mahler Thomas wrote:
Hi Kristian,
For me this does not look like a OJB bug, but as a configuration problem.
If you have a java attribute of type String but have defined it as INTEGER
in the repository.xml you've got a problem!
If you want to have a String attribute converted into an Oracle Number
column you should use a FieldConversion but not change the
PlatformOracleImpl.
cheers,
thomas
-Original Message-----
From: kristian meier [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 9:46 AM
To: OJB Users List
Subject: Re: Possible OJB Bug with Oracle
Hello,
when I yesterday switch to oracle I came across the same
exception and I
investigated a bit, and
found an unexpected situation in the PlatformOracleImpl.java
in the setObjectForStatement( ) method the sqlType was
Type.INTEGER
and the value was a String class
both arguments were passed to the PlatformDefaultImpl.java where they
were passed into the PreparedStatement.
the String class seemed to be already wrong at this place,
but a simple
hack does work fine for me:
*** PlatformOracleImpl.javaSun May 4 14:08:14 2003
---
src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
Thu Jun 5 09:17:58 2003
***
*** 126,131
--- 126,138
ps.setLong(index, ((Integer) value).intValue());
}
+ else if (sqlType == Types.INTEGER && value
instanceof String)
+ {
+ // workaround:
+ ps.setInt(index, Integer.parseInt( (String) value ) );
+ }
else
{
+ this.logger.debug( "using type " + sqlType + " for
class " +
value.getClass().getName()
++ "(" + value + ")" );
super.setObjectForStatement(ps, index, value, sqlType);
}
maybe this also helps to find the real bug !!!
with best wishes Kristian
Brown, Melonie S. - Contractor wrote:
Has anybody else ran into this? This is a big problem for
us, and I'm
catching a lot of flack since I recommended we use OJB.
It appears that OJB is generating a getCollection query even
though the code
specifies a single object.
I'm not sure where to begin debugging, so any assistance
would be greatly
appreciated.
Original Message
Subject: [RC3] Works with MySql, Fails with
ClassCastException with Oracle
Date: Thu, 29 May 2003 11:41:00 -0400
From: Brown, Melonie S. - Contractor <[EMAIL PROTECTED]>
Reply-To: OJB Users List <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.jakarta.ojb.user
I have code that works perfectly fine in MySQL but crashes
and dies against
an Oracle database. I'm getting a java.lang.ClassCastException at
GetCollectionByQuery which doesn't make sense since I'm calling
broker.getObjectbyQuery. Also, no SQL statements show in
the spy.log file.
Suggestions would be greatly appreciated.
This is the code:
public static RcioDB retrieveRcio(RcioDB sRcio) throws
DataStoreException
{
PersistenceBroker broker = GetAccess.getPersistenceBroker();
try
{
broker.beginTransaction();
Criteria crit = new Criteria();
crit.addEqualTo(
Constants.RCIO_ID,
String.valueOf(sRcio.getRcio_ID()));
System.out.println("criteria set");
QueryByCriteria query =
QueryFactory.newQuery(RcioDB.class,
crit);
System.out.println("query created");
Object theRcioToBeFetched =
broker.getObjectByQuery(query);
System.out.println("after fetch");
System.out.println(theRcioToBeFetched.getClass());
return (RcioDB)theRcioToBeFetched;
}
catch (Throwable t)
{
t.printStackTrace();
throw new DataStoreException(t.toString());
}
finally
{
broker.close();
}
This is the output from the log:
criteria set
query created
[org.apache.ojb.broker.accesslayer.ConnectionManagerImpl]
INFO: Rollback was
called, do rollback on current connection
[EMAIL PROTECTED]
org.apache.ojb.broker.PersistenceBrokerException:
java.lang.ClassCastException
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectio
nByQuery(Persis
tenceBrokerImpl.java:1467)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectio
nByQuery(Persis
tenceBrokerImpl.java:1496)
Re: Possible OJB Bug with Oracle
Hello,
when I yesterday switch to oracle I came across the same exception and I
investigated a bit, and
found an unexpected situation in the PlatformOracleImpl.java
in the setObjectForStatement( ) method the sqlType was Type.INTEGER
and the value was a String class
both arguments were passed to the PlatformDefaultImpl.java where they
were passed into the PreparedStatement.
the String class seemed to be already wrong at this place, but a simple
hack does work fine for me:
*** PlatformOracleImpl.javaSun May 4 14:08:14 2003
--- src/java/org/apache/ojb/broker/platforms/PlatformOracleImpl.java
Thu Jun 5 09:17:58 2003
***
*** 126,131
--- 126,138
ps.setLong(index, ((Integer) value).intValue());
}
+ else if (sqlType == Types.INTEGER && value instanceof String)
+ {
+ // workaround:
+ ps.setInt(index, Integer.parseInt( (String) value ) );
+ }
else
{
+ this.logger.debug( "using type " + sqlType + " for class " +
value.getClass().getName()
++ "(" + value + ")" );
super.setObjectForStatement(ps, index, value, sqlType);
}
maybe this also helps to find the real bug !!!
with best wishes Kristian
Brown, Melonie S. - Contractor wrote:
Has anybody else ran into this? This is a big problem for us, and I'm
catching a lot of flack since I recommended we use OJB.
It appears that OJB is generating a getCollection query even though the code
specifies a single object.
I'm not sure where to begin debugging, so any assistance would be greatly
appreciated.
Original Message
Subject: [RC3] Works with MySql, Fails with ClassCastException with Oracle
Date: Thu, 29 May 2003 11:41:00 -0400
From: Brown, Melonie S. - Contractor <[EMAIL PROTECTED]>
Reply-To: OJB Users List <[EMAIL PROTECTED]>
Newsgroups: gmane.comp.jakarta.ojb.user
I have code that works perfectly fine in MySQL but crashes and dies against
an Oracle database. I'm getting a java.lang.ClassCastException at
GetCollectionByQuery which doesn't make sense since I'm calling
broker.getObjectbyQuery. Also, no SQL statements show in the spy.log file.
Suggestions would be greatly appreciated.
This is the code:
public static RcioDB retrieveRcio(RcioDB sRcio) throws DataStoreException
{
PersistenceBroker broker = GetAccess.getPersistenceBroker();
try
{
broker.beginTransaction();
Criteria crit = new Criteria();
crit.addEqualTo(
Constants.RCIO_ID,
String.valueOf(sRcio.getRcio_ID()));
System.out.println("criteria set");
QueryByCriteria query = QueryFactory.newQuery(RcioDB.class,
crit);
System.out.println("query created");
Object theRcioToBeFetched = broker.getObjectByQuery(query);
System.out.println("after fetch");
System.out.println(theRcioToBeFetched.getClass());
return (RcioDB)theRcioToBeFetched;
}
catch (Throwable t)
{
t.printStackTrace();
throw new DataStoreException(t.toString());
}
finally
{
broker.close();
}
This is the output from the log:
criteria set
query created
[org.apache.ojb.broker.accesslayer.ConnectionManagerImpl] INFO: Rollback was
called, do rollback on current connection
[EMAIL PROTECTED]
org.apache.ojb.broker.PersistenceBrokerException:
java.lang.ClassCastException
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis
tenceBrokerImpl.java:1467)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis
tenceBrokerImpl.java:1496)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis
tenceBrokerImpl.java:1485)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getObjectByQuery(Persistenc
eBrokerImpl.java:1747)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.getObjectByQuery(Dele
gatingPersistenceBroker.java:271)
at
mil.army.forscom.tsamsweb.rcio.database.RcioCRUD.retrieveRcio(RcioCRUD.java:
131)
at
mil.army.forscom.tsamsweb.rcio.tests.InsertRciosTest.testInsertRcios(InsertR
ciosTest.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:11
