How reliable is cacheloader and remote cache architecture?

[robinhunter]

I have had a great deal of success implementing a test using Infinispan with a MySql cacheloader, but I have a couple of outstanding questions.

The application is connected to a remote Infinispan cache (which could be a cluster) that is using MySql for persistence. Essentially using a datagrid for object storage helps with the design and performance since once objects are loaded there is quite a bit of referencing but with a low rate of object creation, deletion and update even though the application will need to handle several million objects during the course of a day.

The use of MySql is based on the ability to do on-line backups rather than off-line, which is critical.

The questions are:

1) How reliable is the cacheloader for persitance and is it possible, using hotrod, to determine of the backing store has failed to update.

2) Is this a sensible design (rather than using an L2 cache) and what are the possible downsides.

Thanks

[galder.zamarreno]

Re 1. Reliability depends on the configuration you're using, whether write through (async=false in cache store config) or write behind (async=true). The latter is less reliable (failures don't propagate to the client) but it's faster. With a write through config, any errors updating the DB will be propagated to the client, that will be you sign that something might have gone wrong.

Re 2. It's different design. In the first, the cache or data grid, is the primary source of storage, and the DB is just a backup, whereas the 2nd one the database is the primary source of storage and the cache is used to speed up access to data. The latter is what is done JPA providers such as JPA. The difference of the two depends on your client app, do you want it to talk to a remote cache? or Hibernate?...etc.