Re: Behavior of Connection.commit()
- From: "Angel Saenz-Badillos[MS]" <angelsa@xxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 20 Jan 2006 11:45:37 -0800
"The COMMIT TRANSACTION request has no corresponding BEGIN TRANSACTION."
This could be a very serious error. This may not be what is affecting your
scenario but here is some information that may be applicable. The basic
problem is that high severity SQL exceptions (level 16 or higher) can
rollback the transaction on the server. When this happens the old driver was
masking the error during COMMIT with something like the following TSQL:
IF @@TRANCOUNT > 0 COMMIT TRAN //If there is a transaction active commit
it, otherwise do nothing.
We decided that faking a transaction commit was a bad idea and in the new
driver replaced it with something like:
COMMIT TRAN //Commit transaction, if no transaction active throw exception.
What this means is that the following scenario would behave
//start transaction
//insert data 1
//execute something that throws lev 16 server exception and ignore
exception. At this time insert data 1 has been rolled back!
//insert data 2
//COMMIT
In the old driver in this scenario commit would silently "work" (not throw
an exception), even though insert data 1 has been rolled back. In the new
driver this will now throw an exception and you will at least know that not
all is well. We felt that it was an important breaking change to make.
--
Angel Saenz-Badillos [MS] DataWorks
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging: http://weblogs.asp.net/angelsb/
"Joe Weinstein" <joeNOSPAM@xxxxxxx> wrote in message
news:43D12F02.1060202@xxxxxxxxxx
>
>
> Jerry Brenner wrote:
>
>> Joe, funny meeting you here.
>>
>> We call setAutoCommit(false) when we first get a connection, just prior
>> to putting it into the connection pool. If we need to change it for some
>> reason, then we always change it back before committing.
>>
>
> Hi Jerry! Good to hear from you, and MS will benefit greatly by
> working with you on driver/DBMS query plan issues... I am unable
> to duplicate the problem with the commit() call with some cheap JDBC
> I tried... If you can provide a repro or trace the execution history
> of a connection that throws this exception, that would be cool.
>
> Email me
> j
> o
> e
> AT
> b
> e
> a
> DOT
> c
> o
> m
>
>
>> "Joe Weinstein" wrote:
>>
>>>Wes Clark wrote:
>>>
>>>>Actually, we call setAutoCommit(false) on the connection, we don't issue
>>>>"SET IMPLICIT_TRANSACTIONS ON" via sql.
>>>
>>>Whew, good. I'm sure you know how bad form it would be to mix
>>>transactional
>>>control between JDBC and DBMS-specific SQL. (I've seen it done!). Can you
>>>verify that you *always* call setAutoCommit(false) before calling
>>>commit()?
>>>thanks,
>>>Joe Weinstein at BEA Systems
>
.
- Follow-Ups:
- Re: Behavior of Connection.commit()
- From: Joe Weinstein
- Re: Behavior of Connection.commit()
- References:
- Re: Behavior of Connection.commit()
- From: Joe Weinstein
- Re: Behavior of Connection.commit()
- From: Joe Weinstein
- Re: Behavior of Connection.commit()
- Prev by Date: Re: Behavior of Connection.commit()
- Next by Date: Re: Behavior of Connection.commit()
- Previous by thread: Re: Behavior of Connection.commit()
- Next by thread: Re: Behavior of Connection.commit()
- Index(es):
Relevant Pages
|
