[Zope-DB] working with zope rdbms transaction mgmt

[M.-A. Lemburg]

Jim Abramson wrote:
>>> Is there a reliable way, somewhere within a series of
>> 
>> statements during the request, to effectively commit the connection (without, of course,
>> commit()!)  i've seen 'select sysdate from dual' work at times, as a way of 'committing', but I
>> don't know exactly how dependable this is, or what happens under the hood.
>> 
>> Believe me: you don't want to do that.
>> 
> 
> 
> do what?  select sysdate from dual?  i know i don't want to commit the connection explicitly,
> I've seen the consequences firsthand.  What I was hoping for is a way to insure that the results
> of write op #1, write op #2 are committed before doing write op #3, all in the space of a
> request.
> 
> I guess what you're saying is that there's nothing other than the request's wrapping-up
> exception-free, that will commit activities on a zope-managed connection?  but then, how is it
> that i can see changes i made to the db render on the resulting page, by selecting them back out
> (potentially having used a different connection in the pool to do it)?

Transactions are normally isolated, so there's no way you can see
changes you made on one pending connection using another connection.
All changes become visible once you commit them.

>>> and the converse is also interesting: is there any
>> 
>> reasonable way to 'fool' the tx manager by...uh... letting an exception go up a few levels
>> before trapping it?
>> 
>> Sure, but there's no trickery involved. You can create as many errors as you like as long as
>> Zope gets to finish the request in a proper state (which then results in a call to .commit()
>> internally).
>> 
> 
> if the unhandled exception makes any connections that were involved during the request rollback,
> where does the rollback occur?  is it prior to standard_error_message() or after?
> 
> Is all this behavior documented anywhere? (...ok, ok, silly question, stop laughing!)

Yes: I'd suggest you get a good book on database transactions
and how they work.

The only things to keep in mind when doing Zope programming are:

* don't do explicit commits/rollbacks in your code - Zope does
   that for you

* transactions start and end at request boundaries in Zope
   (just as in most other application servers)

* don't try to play tricks on the transaction manager: you're
   going to lose one way or another

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 09 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::