Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: cdt glossary 0.1.1 [Transaction]

Re: cdt glossary 0.1.1 [Transaction]

From: David Cressey <cressey73_at_verizon.net>
Date: Sat, 21 Apr 2007 10:38:57 GMT
Message-ID: <5RlWh.2831$0d2.189@trndny02>

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:4seWh.103136$6m4.83017_at_pd7urf1no...

> I don't have any problem with "begin transaction" in a programming
> language, but have always found it hard to dig why a dbms would support
> such an idea. But "Commit" bothers me a lot, even in a programming
> language, because I don't see how any other statement that could follow
> it would make any sense except for "begin transaction".

I can think of at least two reasons for separating the action of "commit" from the action of the next "begin transaction".

First, every session has a last transaction. What follows "commit" could be "end session" (sometimes called "disconnect").

Second, many DBMS products offer some kind of "exclusive" transaction mode, in which no other transaction can run conrurrently. If commit were to automatically begin the next transaction, it would either preempt a waiting exclusive transaction, or it would force the process to wait for the end of the exclusive transaction. Sometimes, neither of these actions is what the program wants to do next.

Note in passing, that some dialects of SQL do not support "begin transaction". In this mode, a transaction is implicitly begun any time an action is specified that can only be done in the context of a transaction, and no transaction is running. The "set transaction" in these dialects is a declaration, not an action. Received on Sat Apr 21 2007 - 05:38:57 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US