anonymous wrote : When a cache stops, you are meant to lose this in-memory state. I disagree. When a cache stops, you should lose the ability to operate on the data through the cache interface. I've never seen a database deleting tables when you stop the db server/agent. I would agree with you if a) a stopped cache was not meant to be restarted ever, b) there wasn't a destroy method perfectly suitable for releasing resources. anonymous wrote : | The definitions of the terms are: | ... | stop() - stops the engine and services - which typically includes the data store | ... | I agree. However, stopping a data store's services does not imply deleting the content. anonymous wrote : | The fact that this state stuck around when you stopped and then restarted a cache was a bug. | We need the ability to remove a cache from a cluster and add it to a cluster at runtime, so for us it's clearly a feature and not a bug. I can see your point, but what I don't understand is why you don't let the users make their own decision. anonymous wrote : | You'd use a cache loader if you want a warm cache (even if it is a delegating cache loader that delegates to another in-memory cache that acts as your 'back-end' cache, while your 'front-end' cache adds behaviour) | While we might use something like this eventually, it implies unnecessary code and performance overhead. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068473#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...