[Zope-dev] Re: The remaining spanner in the works :-)

[Chris Withers]

Shane Hathaway wrote:

> I've been trying out a limited-duration cache strategy.  The simplest 
> approach is to clear the cache between transactions.  Alternatively, you 
> can clear the cache periodically.  For a lot of applications this is 
> adequate.

Indeed.

> Another approach, if you can afford it, is triggers.  To do this, you 
> have to know a lot about your database, since there is no standard way.

Yup, I think if both of these were options, then people could use triggers if 
the data store could supply triggers and fall back to cache clearing if it 
couldn't...

> code only allows 8 bytes in _p_serial. ;-) )  This works well enough to 
> detect nearly all conflicts, even though it might not be the speediest 
> solution.

Cool :-)

> And as it turned out, as long as I had conflict detection, it didn't 
> matter as much that the database didn't have the most recent state all 
> the time.  Zope detected conflict errors and retried the transactions, 
> and the second time always worked.  It was good. :-)

Wow, yeah, that sounds pretty cool...

> Finally, here's a theoretical solution that I think would be ideal for a 
> lot of people: if we could just ask the RDBMS for its current 
> transaction ID, Zope could keep track of the last transaction ID it knew 
> about, and clear the caches when another process made a change.  This 
> solution may yield the highest performance for Zope-centric 
> applications.  It would also remove the need for my MD5 hack. ;-)

But would it work for non-transactional storages like file systems?

cheers,

Chris