I think you are right. A quick solution would be to invalidate the cache in
case of a rollback, but there might be an additional problem, at least we
had it in our cache algorithm (an object was present in two delta caches and
modified within two transactions).
In our stores we implemented our own caches, for the Standard store caches
were not limited in size. We re-used an existing in-house technology called
delta caches, where we have a global cache containing all the unchanged
objects and a series of delta caches, each for one transaction. In case of a
commit, the delta cache is copied to the global cache, in case of abort the
delta cache is discarded. Each time a transaction wants to modify an object,
it is either read from the delta cache, or transported there from the global
cache. The transportation method must ensure, that an object is transported
to only one delta cache. Unfortunately our delta cache code is child
dependant.
Best regards
Juergen
-----Original Message-----
From: Christopher Lenz [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 02, 2001 13.58 PM
To: Slide Developers List
Subject: StandardStore caching and transactions
Howdy,
Am I missing something, or do we have a huge problem with the caching
performed by StandardStore and transactions that get rolled back ?
I.e. every modification of the cache inside the transaction will not
be undone if the transaction gets rolled back AFAICT.
An easy solution would be to invalidate the entire cache in
rollback().
But maybe I'm really missing something and the problem doesn't even
exist ;O)
-chris
________________________________________________________________
cmlenz at gmx.de
