Scratch that. After a bit more testing, this causes the Oracle driver to
puke.
++jeff
On Monday 13 May 2002 07:37 pm, Jeffrey Wescott wrote:
> 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(TxInterceptorCM
> > > > > >T. ja va:1 66 ) at
> > > > > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInte
> > > > > >rc ep torC MT . java:526)
> > > > > > at
> > > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.ja
> > > > > >va
> > > > > >
> > > > > >:1 00) at
> > > > > >
> > > > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercep
> > > > > >to r. java
> > > > > >
> > > > > >:1 2 7)
> > > > > >
> > > > > > at
> > > > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:1
> > > > > >70 ) at
> > > > > > org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionCo
> > > > > >nt ai ner. ja v a:286)
> > > > > > at
> > > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRM
> > > > > >PC on tain er I nvoker.java:412)
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI
> > > > > >mp l. java
> > > > > >
> > > > > >:3 9 )
> > > > > >
> > > > > > at
> > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA
> > > > > >cc es sorI mp l .java:25)
> > > > > > at java.lang.reflect.Method.invoke(Method.java:324)
> > > > > > at
> > > > > > sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:26
> > > > > >1) 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.ja
> > > > > >va
> > > > > >
> > > > > >:4 60) at
> > > > > >
> > > > > > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTrans
> > > > > >po 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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
