Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache Life Cycle Clarification #366

Open
cruftex opened this issue Jun 8, 2016 · 0 comments
Open

Cache Life Cycle Clarification #366

cruftex opened this issue Jun 8, 2016 · 0 comments
Milestone

Comments

@cruftex
Copy link
Member

cruftex commented Jun 8, 2016

For example CacheManager.destroyCache() says:

   * 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.

@cruftex cruftex added this to the 2.0 milestone Dec 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant