On Monday 13 May 2002 07:52 pm, David Jencks wrote:
> Now I think I understand what you are saying... but I'm still mystified as
> to how the change in jboss could be causing a problem. If you are using a
> standalone non pooled connection in castor, if you close the prepared
> statement, you can expect it to really be closed, not returned to a
> mysterious pool. So if JBoss does this also, how can this cause a problem?
But I'm *NOT* using a standalone, non-pooled connection in Castor. That's the
point. I'm using a statement taken from JBoss' prepared statement pool. Use
of the XA data source wrapper class does this by default. Using the Oracle
XA data source class with the Oracle Xid class causes the driver to puke.
I'm really stuck here.
Is anyone successfully using Oracle / JBoss 2.4.5 / Castor? If so, please
send some configuration files my way. :-)
++jeff
>
>
> BTW I don't know for sure but have heard that Oracle does rather good
> statement pooling itself.
>
> thanks
> david jencks
>
> On 2002.05.13 22:12:06 -0400 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
> > > > > >rcep torC MT . java:526)
> > > > > > at
> > > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.ja
> > > > > >va:1 00) at
> > > > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityIntercep
> > > > > >tor. java
> > > > > >
> > > > > >:1 2 7)
> > > > > >
> > > > > > at
> > > > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:1
> > > > > >70) at
> > > > > > org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionCo
> > > > > >ntai ner. ja v a:286)
> > > > > > at
> > > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRM
> > > > > >PCon tain er I nvoker.java:412)
> > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > at
> > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI
> > > > > >mpl. java
> > > > > >
> > > > > >:3 9 )
> > > > > >
> > > > > > at
> > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodA
> > > > > >cces 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
> > > > > >port .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
