Cache / application node configuration

Question

Hi!
I am doing a Coherense evaluation and yesterday I talked to the UK Tangosol office that suggested I post these questions here to more quickly get answers. I hope you can help.
I would like to configure a number of nodes to ONLY hold data for a distributed cache. Let us call them cache nodes.
A number of other nodes should be configured to participate in the same distributed cache but not hold any data. They will use a "near" cache with the distributed cache as "back cache". This is the nodes were my application logic will go. Let us call them application nodes.
My first question is if I must have the same configuration on the cache nodes as I have on the application nodes (i.e. must I use a "near cache" even though I do not need or want a "front cache" here since nobody will access the data locally? I assume that the invalidation of even an empty front cache has some associated cost and this is another reason to not have one when not needed.
My second question is if I must make som special provisions in my CacheStore (that will use JDBC to sync with a database) to ensure that modified data will either not be written to either the cache or the database or both (for instance in the event of a critical hardware failure of the cache node calling the CacheStore during a call to one of the "store" or "erase" methods) - or is this "automagically" taken care of some how by the layer above the CacheStore? Is the answer the same or different if I use replication of the data in the replicated cache or not? My plan is to NOT use replication and instead take the hit that some cache data is lost (will be reloaded if needed later) in the event of a critical error killing one of the cache nodes. If I must do something special in the CacheStore to ensure that the database and cache is always coherent I would like some example code that i can start from...
My third question is if my proposed configuration is fully coherent or is it theoretically possible that a client can send a request that modify an object to one of the application node and then (assuming my load balancer is NOT sticky) immediately requests the same data from another application node and get the OLD object value back? I.e. is the update/invalidation from/to the near caches synchronous or asynchronous? If this is a "possible" scenario is there anything that can be done to avoid it with this setup (except getting a sticky load balancer)?
Lastly if you happen to sit on some configuration examples that set up exactly this kind of scenario (or something very close to it) I would appreciate having a look at them. I have found some examples on the forum but none that do the same thing...
Best Regards
MagnusE

Answer 1

Thanks for your quick and informative answer Jon! I need to think more about some of your points to make sure i understand the implications. A few quick follow-up questions though:
With a write-through cache, Coherence will call your
CacheStore implementation before updating the cache,
and so the database will always have the most current
version of the data, even in the event of a cache
server failure.But will the cache also get the new verssion of thew data somehow in the event of a failure (that oocur just after the data has been stored in the database but before the storage node managed to put it in the cache) or will this cause non-coherence between database and cache? Will the application node get an exception back from its put operation in this case (so it at least is aware that the data may not have gone into both the cache and the database)?
What happens if the data store fail to put the data in the database (due to a database constraint or a database failure etc) and the store method in the datastore class throws an exception? Will the storage node still put the new (or changed) object in the cache (causing a non-coherence between databse and cache) or not?
Do you have some documentation that explains how the product handles all the known "corner cases" (like failures during or just after the datastore methods are called etc - it would be valuable since they are often the cause of the rare but really nasty problems...
Best Regards
Magnus
Message was edited by: Magnus
Message was edited by: Magnus