Skip to Content.
Sympa Menu

freetds - Re: Free TDS/JDBC Driver problem .Help

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Kevin Fries" <kelfink AT yahoo.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: Free TDS/JDBC Driver problem .Help
  • Date: Tue, 10 Jul 2001 12:32:33 -0400


Rajeev,

Regarding commit/rollback with the driver, I noticed the same problem. It
turns out to be an interesting choice the author(s) made regarding when to
terminate a transaction. I've never seen this behavior on any other
driver (oracle/mysql/allaire/merant/Inetd) but...

Check out the source code to Statement.java You'll see that it will issue
a rollback call upon close of the statement. This means you have to
explicitly call commit() using the same statement you performed your work
on in order to keep the changes. That's pretty odd, IMHO.

Locally, I've re-coded the source to issue the explicit rollback only upon
close of the Connection. My version still loops through each Statement in
the connection, rolling back each. But when Connection.commit() is
called, my version rolls through each Statement and commits it. I think
this is much closer to the behavior of other JDBC drivers.

I'm still having some odd locking issues, and struggling with issuing a
PreparedStatement.setString() on anything longer than 2k (actually, 2015
bytes) but changing this commit behavior improved things for me quite a
bit.

Related to the commit, I wanted to ask this of the JDBC crew. Has anyone
compared issuing the "set implicit_transactions on" call to issuing a
specific "BEGIN TRAN" call? I don't know if this works with sybase, but
this is the way other commercial drivers work, so I wonder if some locking
issues I have might go away if I recoded it this way? Just curious.

hth,
Kevin Fries
kelfink AT yahoo.com




Archive powered by MHonArc 2.6.24.

Top of Page