[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?

[manik]

Any other comments on this thread? Is everyone happy with what we have?

[belaban]

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.

[manik]

Properties are the contents of the <cacheloader...> element.

See last example (using a FileCacheLoader passing in a location.)

[belaban]

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

[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!

[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>

[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?!?

[belaban]

Looks like we have to treat some CRUDs specially:
- remove
- evict
- put

[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...

[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

[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...

[brian.stansberry]

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.