1 2 Previous Next 17 Replies Latest reply on Aug 9, 2008 12:00 AM by sanne Go to original post
      • 15. Re: Cache @ bootcamp

        Sorry Bela for the messy spelling.
        Maybe it's an indication of the quality of my ideas.

        Just to coroborate the CacheValue local storage of changes: What one could even do (but maybe is not advisable) is compare the values of the tx's version with the commited version, and on a prepare() call not emit an update object. On a rollback one would have to do some cleaning-up operations though, in order to keep the interal CacheValue consistent/small.

        • 16. Re: Cache @ bootcamp

          Hi Belan,

          I'm still around to bug and confuse you!

          Nice to hear that cache will become an XAResource, that'll give me a chance to learn the TX workings while following the Cache project.

          I've read you're update an maybe have a constructive suggestion.

          Since all cached values are wrapped by a CacheValue object you could also use this object to trace the tx/version information of reads/writes/commits. The Cachevalue would then store version and tx information in a map and could then apply all kinds of thread specific heuristics on reading/writing/commiting of a cached value.

          Basically it would be like this. On begin register the XID with the cache. On each change don't write the actual update to a list, but write the CacheID of each 'touched' CacheValue to a map on a change. On prepare or commit you could iterate through this list to gather the information to be committed, for instance the CacheValue could emit an Update object when it's commit is called, or an exception which could then be propagated.

          This has one immediate advantage: if an object is put twice within each transaction, it will only end up once in the map.

          It also has further advantages I think when you would like an instance per transaction/optimistic locking strategy. The cache value object could do several things on the basis of the XID of the current transaction when it reads/writes a value in cooperation with the MVCC Postgresql pattern I posted earlier:

          http://www.linuxgazette.com/issue68/mitchell.html

          and a thread/version tracking list.

          One could track for instance which 'read version' a thread has when it wants to put to a cache on the basis of an CacheValue internal access map, or on commit. All kinds of heuristics could be applied on reading/writing/commiting.

          A second advantage is that changes to the cache values are not only known thread local, but also CacheValue local. A rollback could be issued when for instance a thread tries to put a object in a multiple instance scenario instead of on prepare.

          I've tried to measure through all the possibilities in conjunction with distributed caches/commit options etc, but it soon gets very complex.

          Still I think that this approach could accomodate alot of scenarios.

          Regards,

          Sanne

          • 17. Re: Cache @ bootcamp

            Hi,

            It seems my previous reply (the first after your last...) is still in the pipeline (i.e. lost?)

            Just to be on the safe side, would you be refering to something like:

            http://jakarta.apache.org/commons/jxpath/index.html

            Navigating object graphs (Java Collections, arrays, objects) using XPath? One can use this for instance to query Value Objects in the cache.

            Or do you mean actually doing CMP finds on objects in the cache?

            Regards,

            Sanne

            1 2 Previous Next