[DB-SIG] DBAPI-2.0 clarifications

Federico Di Gregorio fog@mixadlive.com
Mon, 19 Mar 2001 11:27:53 +0100

Scavenging the mail folder uncovered hme@informatik.uni-rostock.de's letter:

> > > yes, i know what isolation level is. my question was about cursors
> > > *derived from the same connection*. now, as you say, isolation level,
> > > where vailable can be set on a "per connection" basis, so, are two
> > > cursors created from the *same* connection **required** to see the
> > > changes immediately or not?
> > >
> > 
> > I believe they are required to see the changes immediately.
> Exactly.

ok. thank you for the clarification.

> > two connections is the only way to isolate the transactions.
> Why would you isolate your program/transaction against what?  The same
> program/transaction?  There is no isolation within one thread of execution,
> one program or one transaction.  It uses the same set of local variable, ...

dbapi defines various levels of thread safety. if your driver is safe at
level 2 or greater a connection can be shared between multiple threads.
maybe you want isolation between *threads*.

> > Essentially, and please correct me if I'm wrong, a cursor is only a
> > statement from a connection and has no transactional ability on
> > it's own, so the connection must handle them as all together or
> > commit on each one.
> I could not see an useful application of having two connections to the
> same database and the same database system from one program.  I mean,
> regardless of how many connections or cursors are open you are always
> in one program and one transaction.  Okay, this gets different if
> multi-threading and nested transactions come into account.

nowdays multithreaded programs are the norm. and if you have a server
that spawns a different thread for every client, you want isolation
of the transactions...


Federico Di Gregorio
MIXAD LIVE Chief of Research & Technology              fog@mixadlive.com
Debian GNU/Linux Developer & Italian Press Contact        fog@debian.org
  Those who do not study Lisp are doomed to reimplement it. Poorly.
                                     -- from Karl M. Hegbloom .signature