* Destroys a specifically named and managed {@link Cache}. Once destroyed
* a new {@link Cache} of the same name but with a different {@link
* Configuration} may be configured.
* <p>
* This is equivalent to the following sequence of method calls:
* <ol>
* <li>{@link Cache#clear()}</li>
* <li>{@link Cache#close()}</li>
* </ol>
* followed by allowing the name of the {@link Cache} to be used for other
* {@link Cache} configurations.
* <p>
This actually implies that after a solely Cache.close() the cache is not destroyed and it may not be created again with the same name.
My critique is:
The Spec defines behavior that is not implemented by the RI.
In the Spec definitions there are some assumptions that an in-process cache could behave different then a persisted cache. Either the different behavior should be defined explicitly, or the behavior should be consistent, and checked by the TCK.
Maybe we find some time and have some ideas to improve here, but probably not in the 1.1 time frame.
For example
CacheManager.destroyCache()says:This actually implies that after a solely
Cache.close()the cache is not destroyed and it may not be created again with the same name.My critique is:
Maybe we find some time and have some ideas to improve here, but probably not in the 1.1 time frame.