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