[Zope-DB] working with zope rdbms transaction mgmt

[Charlie Clark]

On 2004-07-09 at 00:11:49 [+0200], Jim Abramson <jabramson at wgen.net> wrote:
> 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.

Well, this is what the RDBMS will do for you within a single transaction 
assuming the schema is correct and Zope's transactional manager will enforce 
this in the case of other events outside of the database that you might also 
consider essential for this particular "business" transaction. Commit() 
really is binary - yes or no.
 
> 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)?

I'm not sure what you mean here. Of course, you can see the results of your 
transaction on a results page if the transaction was successful. It won't 
matter which connection you are using to do this. There is a nice explanation 
of transactional security and record locking on the PostgreSQL website - it 
was in this week's news.
 
> > > 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?

The standard_error_message should in theory be called after request failure 
and transaction rollback unless you call it explicitly from within the 
request but I think that way madness lies!
 
> Is all this behavior documented anywhere? (...ok, ok, silly question, stop 
> laughing!)

Yes, in the Zope documentation. You should probably spend some time looking 
at the developer docs and probably the source code of the transaction manager.

Charlie
-- 
Charlie Clark
eGenix.com

Professional Python Services directly from the Source
 >>> 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 ! ::::