[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