I too am experiencing this problem, though I'm using a web app with the 
JSTL, and it does not appear to be preventing me from getting the data.

I have a problem with the solution proposed at the end of this.

Basically, Sybase is complaining that a "set chained" method was called 
while a transaction is still outstanding. then issuing a rollback prior 
to the setAutoCommit() doesn't sound right. That may rollback useful 
work, and thus produced undesireable affects.

Here is how I understand things should work. From the code:

      *if* (jdbcAutoCommit && !con.getAutoCommit()) 
      {
         con.setAutoCommit(*true*);
         *return;
      }
*

Now, what this is saying is that using JDBC AutoCommit is enabled 
(jdbcAutoCommit is true), and the connection's current AutoCommit status 
is False. Since that is the case, and this is not a managed transaction, 
then an explicit COMMIT needs to be issued prior to re-setting the 
AutoCommit. Basically, and transaction is pending. Doing a rollback will 
also work, but that is the wrong thing in my opinion.

Maybe the issue is that the connection should be put in AutoCommit mode 
at the beginning, when it is first provided to the app. I'm confused how 
jBoss starts the transaction in cases like Web Apps, etc.

Marc Zampetti

FROM: eniro.com
DATE: 06/06/2002 00:23:44
SUBJECT:  [JBoss-user] jboss 3.0 and BMP/sybase problems

 

Finally, I did manage to get BMP entity beans working somehow... Now there
is this new "sybase" specific problem.
After you get the connection, run your query/stored procedure and then
you close the connection, you endup having ->
--clipclip--
2002-06-05 16:54:24,247 INFO  
[org.jboss.resource.connectionmanager.JBossManagedConnectionPool]
ResourceException returning ManagedConnection to pool:
javax.resource.ResourceException: Could not cleanup: 
com.sybase.jdbc2.jdbc.SybSQLException:
SET CHAINED command not allowed within multi-statement transaction.

        at 
org.jboss.resource.adapter.jdbc.local.LocalManagedConnection.cleanup(LocalManagedConnection.java:198)
        at 
org.jboss.resource.connectionmanager.InternalManagedConnectionPool.returnConnection(InternalManagedConnectionPool.java:137)
        at 
org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.returnConnection(JBossManagedConnectionPool.java:324)
        at 
org.jboss.resource.connectionmanager.BaseConnectionManager2.returnManagedConnection(BaseConnectionManager2.java:494)
        at 
org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener.commit(LocalTxConnectionManager.java:567)
        at org.jboss.tm.TxCapsule.commitResources(TxCapsule.java:1656)
        at org.jboss.tm.TxCapsule.commit(TxCapsule.java:357)
        at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:74)
        at 
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:190)
        at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:61)
        at 
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:129)
        at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
        at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:493)
        at org.jboss.ejb.Container.invoke(Container.java:705)
        at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055)
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491)
        at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:362)
        at java.lang.reflect.Method.invoke(Native Method)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:241)
        at sun.rmi.transport.Transport$1.run(Transport.java:142)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:139)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:443)
        at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:643)
        at java.lang.Thread.run(Thread.java:484)
--clipclip---

Now this is a sybase specific problem, and managed to find that->

When cleanup method in LocalManagedConnection class is called, it goes
and calls checkTransaction.
Now in that method we have:
--clipclip--
.
.
      if (jdbcAutoCommit && !con.getAutoCommit())
      {
         con.setAutoCommit(true);
         return;
      } // end of if ()
--clipclip--
Now this doesnt work with Sybase CHAINED mode, since this getAutoCommit
starts a new transaction. 
So calling setAutoCommit(true) isnt possible without rollbacking/comitting
before (else you endup having this exception : "SET CHAINED command
now allowed within multi-statement transaction").

Somebody in the Expresso mailing-list proposed that: "This only way to
work properly with Sybase is to call rollback (to be
sure there is no more transaction) and then setAutocommit(true). This is
what Poolman and Jakarta DBCP do and it is OK," 

Any comments?



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
JBoss-user mailing list
<EMAIL: PROTECTED>
https://lists.sourceforge.net/lists/listinfo/jboss-user

                



_______________________________________________________________

Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to