Okay. After some experimentation, the following changes in jboss.jcml seem to
fix the JBoss 2.4.5 problems using Oracle:
1- Set the XidClassName attribute in the TransactionManagerService MBean to
oracle.jdbc.xa.OracleXid.
<attribute name="XidClassName">oracle.jdbc.xa.OracleXid</attribute>
2- Set the DataSourceClass attribute in the XADataSourceLoader MBean to
oracle.jdbc.xa.client.OracleXADataSource.
<attribute
name="DataSourceClass">oracle.jdbc.xa.client.OracleXADataSource</attribute>
I haven't throroughly tested any of this ... I'm still tinkering. However,
this lets me succesfully run a smoke test of the system using Castor for
database access on JBoss 2.4.5.
++jeff
On Monday 13 May 2002 07:12 pm, Jeffrey Wescott wrote:
> Ooops. Sorry for the confusion. Let's try that again:
>
> Here's the idea:
> In 2.4.4:
> 1- Castor obtains a PREPARED STATEMENT from the JBoss PREPARED STATEMENT
> pool. 2- Castor does work.
> 3- Castor calls STMT.close() to close the prepared statement.
> 4- JBoss returns the PREPARED STATEMENT to pool.
>
> In 2.4.5:
> 1- Castor obtains a PREPARED STATEMENT from the JBoss PREPARED STATEMENT
> pool. 2- Castor does work.
> 3- Castor calls STMT.close() to close the prepared statement.
> 4- JBoss returns the PREPARED STATEMENT to pool and closes it.
>
> I investigated this further and commenting out the lines in the close()
> method of the PreparedStatementInPool class make it work as it did in
> 2.4.4.
>
> if( impl != null )
> impl.close();
>
> It looks like this patch (#532376) was committed to fix bug #478882, but it
> seems to have caused another problem.
>
> For what it's worth, I'm using Oracle 8.x with classes12.zip. Any idea
> whether or not it does its own prepared statement pooling? Also, how do I
> turn OFF the pooling in JBoss to try to get this stuff to work WITHOUT
> changing code?
>
> ++jeff
>
> On Monday 13 May 2002 07:02 pm, David Jencks wrote:
> > Your statements don't appear to me to be internally consistent. You
> > appear to think closing a PreparedStatement and a Connection are the same
> > action. This makes it difficult for me to follow what you are claiming.
> >
> > Although I try to stay as far away as possible from the
> > XADataSourceLoader code in jboss 2.x, I am quite sure that:
> >
> > calling conn.close() on a connection (handle) returns it to the pool
> >
> > calling ps.close on a prepared statement at one time returned the
> > prepared statement to a pool also. This didn't work with some drivers,
> > so I believe the prepared statement pooling was turned off. IMNSHO
> > prepared statement pooling should not be in a default jdbc wrapper, since
> > any decent db/driver will do its own prepared statement pooling anyway,
> > that a wrapper should not interfere with.
> >
> > If you distinguish between connections and prepared statements, can you
> > explain the problem again?
> >
> > david jencks
> >
> > On 2002.05.13 21:01:42 -0400 Jeffrey Wescott wrote:
> > > Investigating the problem further, it looks as if a change was made to
> > > the
> > > org.jboss.pool.jdbc.PreparedStatementInPool class that actually closes
> > > the
> > > prepared statement when the pool statement is closed.
> > >
> > > This is BAD for us, because Castor was written assuming a non-pooled
> > > environment, closing its prepared statements "as it goes along".
> > >
> > > Here's the idea:
> > >
> > > In 2.4.4:
> > > 1- Castor obtains a connection from the JBoss connection pool.
> > > 2- Castor does work.
> > > 3- Castor calls conn.close() to close the prepared statement.
> > > 4- JBoss returns connection to pool.
> > >
> > > In 2.4.5:
> > > 1- Castor obtains a connection from the JBoss connection pool.
> > > 2- Castor does work.
> > > 3- Castor calls conn.close() to close the prepared statement.
> > > 4- JBoss closes the prepared statement.
> > >
> > > It looks like this patch () was committed to fix bug #478882. I'll
> > > post to
> > > jboss-devel and hope for an answer there. Also, I'll try reverting
> > > that patch to see if Castor works again.
> > >
> > > ++jeff
> > >
> > > On Monday 13 May 2002 05:35 pm, Jeffrey Wescott wrote:
> > > > I am having the same problem. <sigh>
> > > >
> > > > ++jeff
> > > >
> > > > On Thursday 11 July 2002 06:47 am, Andrew wrote:
> > > > > Hi, I've tried to use Castor under 2.4.5 and got:
> > > > > java.sql.SQLException: Closed Statement
> > > > > at
> > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invokeNext(TxInterceptorCMT.
> > > > >ja va:1 66 ) at
> > > > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterc
> > > > >ep torC MT . java:526)
> > > > > at
> > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java
> > > > >:1 00) at
> > > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercepto
> > > > >r. java
> > > > >
> > > > >:1 2 7)
> > > > >
> > > > > at
> > > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170
> > > > >) at
> > > > > org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionCont
> > > > >ai ner. ja v a:286)
> > > > > at
> > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPC
> > > > >on tain er I nvoker.java:412)
> > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > at
> > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp
> > > > >l. java
> > > > >
> > > > >:3 9 )
> > > > >
> > > > > at
> > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc
> > > > >es sorI mp l .java:25)
> > > > > at java.lang.reflect.Method.invoke(Method.java:324)
> > > > > at
> > > > > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> > > > > at sun.rmi.transport.Transport$1.run(Transport.java:148)
> > > > > at java.security.AccessController.doPrivileged(Native Method)
> > > > > at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> > > > > at
> > > > > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java
> > > > >:4 60) at
> > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTranspo
> > > > >rt .jav a: 7 01)
> > > > > at java.lang.Thread.run(Thread.java:536)
> > > > >
> > > > > but with 2.4.4 all was ok.
> > > > > Test:
> > > > > 1-1 relationship
> > > > > sessionEJB.getMaster1().getMaster2();// two times- second time
> > > > > throws exception.
> > > > > What could be wrong?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > -----------------------------------------------------------
> > > > > If you wish to unsubscribe from this mailing, send mail to
> > > > > [EMAIL PROTECTED] with a subject of:
> > > > > unsubscribe castor-dev
> > > >
> > > > -----------------------------------------------------------
> > > > If you wish to unsubscribe from this mailing, send mail to
> > > > [EMAIL PROTECTED] with a subject of:
> > > > unsubscribe castor-dev
> > >
> > > -----------------------------------------------------------
> > > If you wish to unsubscribe from this mailing, send mail to
> > > [EMAIL PROTECTED] with a subject of:
> > > unsubscribe castor-dev
> >
> > -----------------------------------------------------------
> > If you wish to unsubscribe from this mailing, send mail to
> > [EMAIL PROTECTED] with a subject of:
> > unsubscribe castor-dev
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
