anonymous wrote : 1. Is it possible to do reads and writes in batches? Obviously, if I have 1 million records and I want to preload them all, it's better to do one "SELECT *" rather than one "SELECT ID" followed by 1 million "SELECT * WHERE ID=?". JDBCCacheLoader works like that (starting with 2.0). anonymous wrote : | Similarly, if I have 1 million updates to perform, it's better to group them in batches (asynchronously), and reduce the number of db transactions. Nice one, I've created http://jira.jboss.com/jira/browse/JBCACHE-1221 for this. anonymous wrote : | 2. When I add a new cache to the replicated cluster (with a shared cache loader), can it preload all the necessary data from the cache loader (not blocking the cluster in any way during this operation), and then get the latest changes from the cluster (*all* and *only* the changes) so that it is up to date? | You can disable state transfer then and preload data on startup. If other caches write async then this won't work, though. We have some ideas of handling state transfer more efficiently, but not a clear date on when those will be implemented anonymous wrote : | 3. I understand that with a shared cache loader, the cache that originates a change is also the one that writes it to the cache loader. yes anonymous wrote : What happens if the cache loader writes asynchronously, and that cache instance goes down after completing the transaction but before flushing the data to the db? Is it possible to have another cache write it instead? Not. After all that's the drawback of having async writings, you're not gonna be notified whether they failed or not. If it's critical for you to know the data is persisted I think you should use sync replication. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4106062#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...