[Z3-sqlos] RFC: Transaction simplification branch

Brian Sutherland jinty at web.de
Fri Dec 9 14:18:55 CET 2005


On Fri, Dec 09, 2005 at 06:54:51PM +0700, Stuart Bishop wrote:
> Brian Sutherland wrote:
> > On Fri, Dec 09, 2005 at 12:50:45PM +0700, Stuart Bishop wrote:
> > 
> >>>>|  * Why do we expire objects in a successful transaction? I can't think
> >>>>|    of a reason why we need to.
> >>
> >>You need to expire objects after a successful transaction so you can see
> >>database changes made by other processes or threads. This is particularly
> >>important for Zope where you have a number of handler threads and possibly
> >>multiple application servers in a ZEO environment.
> > 
> > Great, I reverted my patch and added a big warning because I don't want
> > to imagine writing a test for that.
> > 
> > But there is another issue with what you bring up, so far we only expire
> > objects that have been changed during the transaction. By what you say,
> > we should be expiring _every_ object on our thread.
> 
> Yes - in our app we blow away the thread's entire cache at the transaction
> start (but our publisher and sqlos layers have been customised/lobotomised
> enough to not be generally useful to others).
> 
>         name = getUtility(IConnectionName).name
>         key = (thread.get_ident(), name)
>         cache = sqlos.connection.connCache
>         if cache.has_key(key):
>             del cache[key]

Doesn't this leave the problem of objects you have a reference to
in your app, but have not changed? Not very common I imagine...

Anyway, thanks for the great suggestions/discussion, I marked it down in
the TODO list until I have some more free time.

-- 
Brian Sutherland

Metropolis - "it's the first movie with a robot. And she's a woman.
              And she's EVIL!!"



More information about the z3-sqlos mailing list