I just submitted a note to the jboss-development mailing list on this topic.
Let's wait and see what they say.
++jeff
On Tuesday 14 May 2002 12:51 pm, Oleg Nitz wrote:
> Hi,
>
> I ran into the same problem and did the same fix to JBoss as Jeffrey, but I
> don't think the problem is really related to Castor, I count this as
> a recently introduced bug in JBoss. Look, JBoss has a pool of
> PreparedStatements for the given Connection so that they are reused.
> After
> if( impl != null )
> impl.close();
> the impl remains in the pool and can be returned next time when the same
> SQL statement is prepared for the same Connection. Castor just prepare the
> same SQL statements many times, that's all of Castor specific here.
> So I suppose that the bug #478882 was fixed incorrectly.
>
> Regards,
> Oleg
>
> On Tuesday 14 May 2002 05:52, 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?
> >
> >
> > 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(TxInterceptor
> > > > > > >CM T.ja va:1 66 ) at
> > > > > > > org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxIn
> > > > > > >te rcep torC MT . java:526)
> > > > > > > at
> > > > > > > org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.
> > > > > > >ja va:1 00) at
> > > > > > > org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterc
> > > > > > >ep tor. java
> > > > > > >
> > > > > > >:1 2 7)
> > > > > > >
> > > > > > > at
> > > > > > > org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java
> > > > > > >:1 70) at
> > > > > > > org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSession
> > > > > > >Co ntai ner. ja v a:286)
> > > > > > > at
> > > > > > > org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker.invoke(J
> > > > > > >RM PCon tain er I nvoker.java:412)
> > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > > > > at
> > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccesso
> > > > > > >rI mpl. java
> > > > > > >
> > > > > > >:3 9 )
> > > > > > >
> > > > > > > at
> > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMetho
> > > > > > >dA 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(TCPTra
> > > > > > >ns 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
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
