[Zope-DB] working with zope rdbms transaction mgmt

[Jim Abramson]

> > 
> > 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)?


> > 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!)


Jim