Remove rollback() after getAutoCommit() is throwing an exception

Tarek Hammoud

unread,

Jul 12, 2002, 3:38:45 PM7/12/02

to

Hello,

SP3's removal of rollback() after getAutoCommit() is causing sybase JConnect
to throw this exception:

com.sybase.jdbc2.jdbc.SybSQLException: SET CHAINED command not allowed
within m
lti-statement transaction.

at com.sybase.jdbc2.tds.Tds.processEed(Tds.java:2636)
at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:1996)
at
com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69)
at
com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:204)
at
com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:187)
at
com.sybase.jdbc2.jdbc.SybStatement.updateLoop(SybStatement.java:1642
at
com.sybase.jdbc2.jdbc.SybStatement.executeUpdate(SybStatement.java:1
25)

Please FIX or provide a patch. I have wrapped the connection in both SP2
(works) and (SP3), it does not work because the call to rollback() is
missing.

Tarek Hammoud

unread,

Jul 12, 2002, 4:14:04 PM7/12/02

to

From : Joseph Weinstein on an old post:

"
if (conn.getAutoCommit()) conn.setAutoCommit(false);
if (!conn.getAutoCommit()) conn.setAutoCommit(true);

If executed on a brand-new connection will fail, because the driver does not
retain the auto-commit state of the connection at the client, but rather
goes to the DBMS to ask, every time getAutoCommit() is called.
Unfortunately,
the very act of asking the DBMS for the mode is interpreted by the DBMS as
instantiating transactional content, when in chained mode (at least for the
default transaction isolation level), so when the second call to
setAutoCommit()
is made, the DBMS fails it, thinking a commit or rollback is necessary
first.
But I digress.
"

Tarek Hammoud <tham...@yahoo.com> wrote in message
news:3d2f...@newsgroups2.bea.com...

Tarek Hammoud

unread,

Jul 15, 2002, 11:18:29 AM7/15/02

to

Joe,

The patch does not fix the problem. However, wrapping the connection and
calling rollback after every getAutoCommit() works.

Tarek

Joseph Weinstein <j...@bea.com> wrote in message
news:3D2F4F23...@bea.com...
> Hi Tarek!
> Yep. Here's a patch you can try. Add it as the first thing in the 6.1
> server classpath. This will also give you the beneficial side-effect of
> a faster pool. Let me know if it fixes things.
> Joe

Tarek Hammoud

unread,

Jul 18, 2002, 5:36:21 PM7/18/02

to

Problem fixed with a private patch. Thanks Joe.

Tarek Hammoud <tham...@yahoo.com> wrote in message

news:3d32e78d$1...@newsgroups2.bea.com...

Martin Koch

unread,

Jul 19, 2002, 4:39:02 AM7/19/02

to

Hallo Joe,
Hallo Tarek,

I have a similar problem with the Sybase jConnect Driver.
Here are the Details:
I have implemented a simple Entity EJB with CMP. The underlying
TxDataSource uses a ConnectionPool with the following
configuration:

When I try to run a test client the following exception occurs:

com.sybase.jdbc2.jdbc.SybSQLException: SET CHAINED command not allowed within

multi-statement transaction.

at com.sybase.jdbc2.tds.Tds.processEed(Tds.java:2636)
at com.sybase.jdbc2.tds.Tds.nextResult(Tds.java:1996)
at com.sybase.jdbc2.jdbc.ResultGetter.nextResult(ResultGetter.java:69)
at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:204)
at com.sybase.jdbc2.jdbc.SybStatement.nextResult(SybStatement.java:187)

The problem exists only with WLS 6.1 SP3. SP2 works!. I think the problem is
that WLS checks the commit-mode of the Sybase Database. This check starts a new
database transaction. If the commit mode is auto-commit, WLS tries to change the
mode. This causes an error because there exists an open transaction. Consequently,
WLS should initiate a rollback or commit after the check to end the transaction.

In your prior postings I have read that there exist a fix to the problem. May
be you can send me the solution to the problem.
Thanks for your support,

Martin Koch

Joseph Weinstein

unread,

Jul 19, 2002, 1:34:48 PM7/19/02

to Martin Koch

Martin Koch wrote:

> Hallo Joe,

Let me know if the jar I sent you does the trick.
Joe