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?
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(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
>
>
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
