-
15. Re: ChainingCacheLoader initial designs
manik Oct 26, 2005 2:38 PM (in response to manik)How about passivation though? I presume if passivation is enabled we don't bother with a cache loader chain and just use the first cache loader configured, ignoring the rest? What's the point of passivating to a chain of cache loaders?
-
16. Re: ChainingCacheLoader initial designs
manik Oct 28, 2005 7:16 AM (in response to manik)Any other comments on this thread? Is everyone happy with what we have?
-
17. Re: ChainingCacheLoader initial designs
belaban Oct 28, 2005 8:35 AM (in response to manik)How do we feed the properties of a CacheLoader (e.g. async, location and so on) to the CacheLoader ? Same as now, a properties list ? This would be good, because now every cache loader can configure itself, and accept any parameters. Think about JDBCCacheLoader; this one has a lot of options.
-
18. Re: ChainingCacheLoader initial designs
manik Oct 28, 2005 8:43 AM (in response to manik)Properties are the contents of the <cacheloader...> element.
See last example (using a FileCacheLoader passing in a location.) -
19. Re: ChainingCacheLoader initial designs
belaban Oct 28, 2005 8:48 AM (in response to manik)I just want to make sure existing CacheLoader impls don't break. So we can remove all props that we handle, e.g. "async", then feed the rest to the CacheLoadet.setConfig(Properties) method
-
20. Re: ChainingCacheLoader initial designs
manik Oct 28, 2005 9:04 AM (in response to manik)yep, precisely. And like we said, writing a conversion script won't be that hard either - although that's gotta be a pretty low prio task!
-
21. Re: ChainingCacheLoader initial designs
manik Nov 7, 2005 7:35 AM (in response to manik)Finalising on a config format like:
<passivation>false</passivation> <cacheloader> <class>org.jboss.cache.loader.FileCacheLoader</class> <async>false</async> <shared>false</shared> <fetchTransientState>false</fetchTransientState> <fetchPersistentState>false</fetchPersistentState> <ignoreModifications>false</ignoreModifications> <preload>/</preload> <properties> location=/tmp/file.db </properties> </cacheloader> <cacheloader> <class>org.jboss.cache.loader.bdbje.BdbjeCacheLoader</class> <async>true</async> <shared>false</shared> <fetchTransientState>false</fetchTransientState> <fetchPersistentState>false</fetchPersistentState> <ignoreModifications>false</ignoreModifications> <preload>/</preload> <properties> location=/mnt/shared/je.db </properties> </cacheloader>
-
22. Re: ChainingCacheLoader initial designs
manik Nov 14, 2005 1:29 PM (in response to manik)Hello all.
A quick question regarding semantics of chaining cache loaders.
When we have 2 cache loaders in a chain (loader1 and loader2), the basic assumption is that when doing a get(), the CCL looks first in loader1, and if it gets a null, looks in loader2.
Now what happens when we set ignoreModifications to true on loader2? We basically ignore all CRUD operations on this cache loader.
So we have this situation:
1. Loaders 1 and 2 are initialised with some data, say /a/b.
2. Cache does a remove() on /a/b
3. Loader1 does the remove of /a/b
4. Loader2 ignores the CRUD.
5. Cache does a get() on /a/b, null in memory
6. Loader1 finds a null.
7. Loader2, however, still has the initial value.
Makes me think - is ignoreModifications really something useful?!? -
23. Re: ChainingCacheLoader initial designs
belaban Nov 14, 2005 2:16 PM (in response to manik)Looks like we have to treat some CRUDs specially:
- remove
- evict
- put -
24. Re: ChainingCacheLoader initial designs
manik Nov 14, 2005 2:36 PM (in response to manik)Are you suggesting that ignoreMods only ignores put(), but not remove()?
How will it handle put(fqn, key, null), which as far as a single data element is concerned, is the same as a remove()? A 'special case' to watch out for specifically, I think?
And even if we treat them differently, is ignoreModifications actually useful to anyone if it only ignores put() but not remove()? I suppose data transient to a specific cache will not make it back to a generic cache store this way... -
25. Re: ChainingCacheLoader initial designs
manik Nov 15, 2005 10:01 AM (in response to manik)I have updated the documentation (docs/treecache/en/master.xml) with info on chaining cache loaders and have updated it accordingly re: the new configuration XML block.
If someone's waiting for a build or test suite to complete, could you pls have a proof read of this for me? I'd appreciate some feedback.
Thanks,
Manik -
26. Re: ChainingCacheLoader initial designs
manik Nov 15, 2005 10:52 AM (in response to manik)Given that most of the cache loader configs now sit within the cache loader manager, a bunch of the old getters and setters have been removed from TreeCache.
Should I put these accessors back in (for backward compatibility) but mark them as deprecated and no-op?
Or is it better to mark them as deprecated, but have them modify corresponding properties in the cache loader manager?
Just concerned about people who programatically configure the cache loaders... -
27. Re: ChainingCacheLoader initial designs
brian.stansberry Nov 15, 2005 11:59 AM (in response to manik)Leaving the old API caused me a bit of trouble. The internal conversion of the old setFetchStateOnStartup() to setFetchInMemoryState() broke a test, as the semantics of the two aren't quite the same. I set fetchStateOnStartup to false to prevent *initial* state transfer, but then when I requested a partial state transfer via activateRegion(), I didn't get the in-memory state.
So, if we can't guarantee that an old bit of API is going to have the same behavior as previously, I think it's better to do away with it. Either way backwards compatibility is broken, but with the API removed at least this fact is more obvious to the user.