[Zope] More on understanding conflicts

[Dennis Allison]

Thanks again Chris for the helpful comments.  

The navigation_box, in this context is just a table which is rendered 
into a frame in our standard frameset.  It is not an iframe.

In the sense I used them below, a transaction and a request are the same
thing.  This follows from the fact that each request is managed as a
single transaction.  Perhaps it would have been a better choice of words
to use "request".

I suggested breaking the request into two requests as one way to help
manage conflicts.  Only the first part of the the split request would 
reference the session variables, so the window of opportunity for a 
session variable conflict would be smaller even though the number of 
requests is larger.  

And, sigh, you are probably right--it may be time to abandon the standard 
release session implementation and roll our own.


On Wed, 21 Dec 2005, Chris McDonough wrote:

> >> Write conflicts happen for a transaction.  In Zope, there is one
> >> transaction per request.
> >
> > There are two distinct sections to the navigation_box transaction.
> 
> There's a transaction for something named "navigation_box"?  Is this  
> an IFRAME?
> 
> >   One
> > where the session variables are read and a second where they are  
> > used. To
> > minimize conflicts, the what is now a single tranaction should be  
> > split
> > into two separate transactions.
> 
> Are you maybe misusing the term "transaction" here?  If this logic  
> all happens in the course of a single request, it all happens in the  
> same transaction unless that request causes, say, the reload of a frame.
> 
> There is a concept of a transaction here.  But it doesn't have  
> anything to do with what happens during the course of a single  
> request unless you explicitly try to control transactions, which is  
> almost never a good idea.
> 
> > Any thought as to how to do that?  If navigation_box were broken into
> > two separate methods, say nav_box1 and nav_box2, how does nav_box1
> > commit itself and then transfer control and data (a session variable
> > snapshot) to nav_box2 as a new transaction?
> 
> I suspect I don't understand what this would achieve.  Having more  
> transactions will cause more conflicts.  Conflicts happen as a result  
> of conflicting changes in two transactions.
> 
> > I would guess that if nav_box1 redirects to nav_box2 a new transaction
> > is initiated and the old one committed.  Is that correct?  And is  
> > there
> > a better way to get the same effect?
> 
> I have no idea, sorry.
> 
> I think maybe what you might want to do here is to not use builtin  
> Zope sessions. ;-)  Zope sessions rely on ZODB and are  
> transactional.  If they didn't rely on ZODB, you wouldn't be getting  
> conflict errors.  If they weren't transactional, you probably  
> wouldn't notice.
> 
> Might be time to cut bait here.  We've been talking about this for  
> months. ;-)  I think someone wrote a relational database backend for  
> the sessioning API some time ago.  You may want to give that a shot.
> 
> - C
> 

--