1 Reply Latest reply on May 8, 2003 9:18 PM by davidjencks

    JBoss closes connection of stateful session bean between met

    udoschwedt

      Hi folks,

      I'm having a problem with JBoss 3.2.1.

      I have a stateful session bean which provides access to results of a DB request.
      On the first call (method start()), it opens a DB connection, creates and executes a prepared statement, stores Connection, Statement and the resulting ResultSet in member variables and returns the first 50 entries of the result set.
      On the next call (method next()), it tries to read the next 200 entries of the ResultSet. This worked fine with 2.4.x, but with 3.2.1, JBoss complains about the following things:

      16:34:37,231 WARN [WrappedConnection] Closing a statement you left open, please do your own housekeeping
      16:34:37,241 INFO [CachedConnectionManager] Successfully closed a connection for you. Please close them yourself: org.jboss.resource.adapter.jdbc.WrappedConnection@1d1695e
      java.lang.Exception: Stack Trace

      The next() call fails as the ResultSet.next() method trows an exception :-(

      The bean is a stateful session bean with bean managed transactions, the data source is configured as a no-tx-datasource.

      I wonder why JBoss complains about me not closing the connection. While it is true that the statement and the connection are left open, this happened on purpose - the bean is stateful, anyway.

      I gave it a shot to change the standardjboss.xml and removed the
      org.jboss.resource.connectionmanager.CachedConnectionInterceptor
      line, and the error didn't appear any more - but I guess the interceptor is there for a reason, so I suspect its removal will cause some unwanted side effects, or am I just paranoid?

      Any help would be highly appreciated.

      Thanks in advance,
      Udo

        • 1. Re: JBoss closes connection of stateful session bean between
          davidjencks

          Rather than removing the CachedConnectionInterceptor, find the configuration of the CachedCOnnectionManager mbean and set SpecCompliant to true.

          You may also need to mark the resource as unsharable if the calls are in different transactions. If they are in the same transaction and you are using an xa datasource be sure to include the track-connections-by-tx element.