"supi" wrote : | 1) API changes | There's already a thread about this regarding listener notification. |
That selfsame thread contains explanations as to why this was done, along with links to other threads where this was publicly discussed beforehand. "supi" wrote : | 2) Behavior changes | - Cache data is removed when a cache is stopped. This has never been the case before. I know that it was written somewhere in the documentation since 1.2 or so but it was a concept that didn't make sense to begin with. Who would have thought that someone is actually going to implement this... Data can easily be removed manually if indeed necessary, doing it in stop is pointless: stop() should stop the cache, destroy() should destroy it. Now stop() partially destroys it and destroy contains some code that is even redundant. (you can tell me not to rely on undocumented features and you are right, but missing the point: somthing that has been there for 5 years shouldn't be removed between two candidate releases) | This was tagged for 2.0.0 as a part of the API change but wasn't properly unimplemented till pretty late. Caches are meant to me in-memory stores for data. When a cache stops, you are meant to lose this in-memory state. The fact that this state stuck around when you stopped and then restarted a cache was a bug. The definitions of the terms are: create() - sets up and configures the cache for use start() - starts the caching engine, and relevant services stop() - stops the engine and services - which typically includes the data store destroy() - releases resources and configuration elements 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), or configure the cache to fetch in-memory state from it's neighbours on startup. "supi" wrote : | Cache restart (stop/start) is broken. When a cache is started in local mode first and then restarted in async mode, initial state transfer works, but updates at runtime don't because half the mode-dependent stuff is in create and half in start which renders a restarted cache unusable. This was not the case in RC1. | This I can see as a bug. Will try and reproduce and create a JIRA accordingly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068436#4068436 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068436 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
