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(TxIntercep
> > > >torC MT . java:526)
> > > > at
> > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:1
> > > >00) at
> > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.
> > > >java
> > > >
> > > >:1 2 7)
> > > >
> > > > at
> > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:170)
> > > > at
> > > > org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContai
> > > >ner. ja v a:286)
> > > > at
> > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(JRMPCon
> > > >tain er I nvoker.java:412)
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> > > >java
> > > >
> > > >:3 9 )
> > > >
> > > > at
> > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> > > >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(TCPTransport
> > > >.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
