Skip to Content.
Sympa Menu

freetds - Re: JDBC bug?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brett Knights <knights AT tanner.com>
  • To: "'TDS Development Group'" <freetds AT franklin.oit.unc.edu>
  • Subject: Re: JDBC bug?
  • Date: Thu, 24 Feb 2000 12:51:03 -0800



-----Original Message-----
From: bounce-freetds-101769 AT franklin.oit.unc.edu
[mailto:bounce-freetds-101769 AT franklin.oit.unc.edu]On Behalf Of Eric
Mountain
Sent: Thursday, February 24, 2000 11:47 AM
To: TDS Development Group
Subject: [freetds] Re: JDBC bug?


>(1) I can't reproduce this if I use the same Statement object for
UDPATE and SELECT:
>if it were the case it would be very strange since the row is locked by
the UPDATE
>and the SELECT is in the same transaction. I won't even try to use 2
different
>Statement objects since (provided autoCommit is false) I know that I
will get
>that behaviour as it is what I would expect: freetds allows you to have
thread-safe
>Statements on the same Connection by having a _physical_ connection to
the database
>per Statement object. So if you UPDATE on one Statement (and don't
commit) and SELECT>
>on another Statement, then the SELECT will block until the UDPATE is
commited because
> they are in 2 different transactions. This is not a bug, this is
ACID.

But not correct:
Statements created from the same connection object shouldn't block each
other. They are all part of the same transaction and should have the
same view of the database. I don't know it that is per spec but that is
how all systems I have ever used work. You should be able to begin a
transaction on a connection , create and close any number of statements
and then commit or roll-back the entire transaction.
The way freetdsJDBC is currently implemented your statements get rolled
back if you close them without committing. Essentially the user has to
treat a statement in freetdsJDBC as they would a connection using any
other driver. In my mind this nulls any thread safe benefit you might
have by the strategy that has been adopted so far.

In fact who cares about thread-safe connections: It seems easy enough to
manage connections for thread safety as required by your application.

Also you can't (I can't anyway) call setAutoCommit(true). When I try I
get a "protocol confusion" message. (I posted this to linuxCare - is
that working?) This is from the latest CVS using jdk 1.22 on Win95.
Sources compiled with Jikes. target db MS-SQL Server 6.5.





Archive powered by MHonArc 2.6.24.

Top of Page