SingletonStoreCacheLoader in 2.0

[galder.zamarreno]

Couple of things came to my mind while I was coding this:

- AsyncCacheLoader and SingletonStoreCacheLoader share the same
paradigm in that none of them write to the actual store, but delegate to an
underlying cache loader. I thought about extending the CacheLoader
interface, creating an interface named DelegatingCacheLoader. This would
containg a getCacheLoader() method that would return the underlying
CacheLoader instance. This would also simplify
CacheLoaderInterceptor.isCustomCacheLoaderConfigured() implementation
as the instanceOf would be done by DelegatingCacheLoader instead of the
individual caches.

- Also, let's say a customer creates a singleton and async cacheloader. The
delegating order should not be any problem, but I'd quite likely have singleton
on top so that if the node is not the coordinator, don't even bother with the
async layer.

[vblagojevic]

Whoever wrote CacheLoaderInterceptor.isCustomCacheLoaderConfigured() is a very creative person ! IMO you have to come up with more good reasons why you would do what you propose other than improving already a nicely written method:) Are you almost done SingletonStoreCacheLoader?


Why not create AbstractDelegatingCacheloader class that combines things that are common to all future delegating cacheloaders. One of them is getCacheLoader method but I would implement all cacheloader methods in AbstractDelegatingCacheloader with delegates. Subclasses then just have to override specific methods. For example, I am looking at AsyncCacheLoader and it needs to override only half a dozen methods.

What do you think?

[galder.zamarreno]

Chill mate! :-), I just realised this on a flight back to Switzerland and I still
haven't had the chance to sit down and look at the ramifications and
extra possible benefits. This thread was intended to pitch the idea and get
some feedback.

The original thought, and therefore the main reason, was that both cache
loaders share the same aspect which is, delegating the work on another
cache loader as I already pointed out.

The second point, and the one I found after realising the first one,
regarding isCustomCacheLoaderConfigured() was just an example of the
benefits. I haven't looked at this method in detail yet.

I will indeed look at the exact similarities between the two and see which
aspects can be abstracted to this upper layer.

Thanks

[manik]

Whoever wrote CacheLoaderInterceptor.isCustomCacheLoaderConfigured() is a very creative person !

If you were being serious, I'll take credit for it - if you were being sarcastic, I have no idea who wrote that! :-)

Why not create AbstractDelegatingCacheloader class that combines things that are common to all future delegating cacheloaders. One of them is getCacheLoader method but I would implement all cacheloader methods in AbstractDelegatingCacheloader with delegates. Subclasses then just have to override specific methods. For example, I am looking at AsyncCacheLoader and it needs to override only half a dozen methods.

I think this is a good idea, since the majority of cases the call is just passed to the underlying loader. If someone just extends the AbstractDCL he'd end up with the same basic features of the underlying cache loader, and any added behaviour will have to be introduced by overriding methods. It would have to be javadoc'd pretty clearly to that effect.

[vblagojevic]

If you were being serious, I'll take credit for it - if you were being sarcastic, I have no idea who wrote that! :-)

No sarcasam tags around it! Cheers.