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

Unmanaged / annonymous cache #24

Closed
cruftex opened this issue Nov 25, 2015 · 4 comments
Closed

Unmanaged / annonymous cache #24

cruftex opened this issue Nov 25, 2015 · 4 comments

Comments

@cruftex
Copy link
Member

cruftex commented Nov 25, 2015

At the moment every cache needs a unique name.

This is needed to have an unique identifier for JMX. We will need it later for external cache configuration, too.

The unique name requirement leads into trouble, when the cache instance has only a temporary or limited lifetime. Applications need to take care that a cache is properly destroyed since it is not garbage collected.

TODO:

  • Support for a cache that needs no name
  • Cache should be GCd when originator has no more reference on it
  • We should keep a WeakReference / make statistics available what caches exist
  • on finalize we need to do a proper destroy and make sure the cache has no
    thread/timers.
@cruftex cruftex added this to the v1-RC1 milestone May 24, 2016
@cruftex cruftex modified the milestones: v1.2, v1-CR1 Dec 5, 2016
@cruftex
Copy link
Member Author

cruftex commented Dec 5, 2016

Dropping this for v1, since we have no real use for it at the moment.

@cruftex cruftex modified the milestones: v1.2, v1.4 Jul 10, 2018
@cruftex cruftex removed this from the v1.4 milestone Aug 21, 2019
@cruftex
Copy link
Member Author

cruftex commented Aug 21, 2019

Current status:
If no name is specified a unique name is generated. This means caches can be created dynamically without the need of giving them a name.

I see that EHCache 3 has a UserManagedCache which is not associated to a cache manager. However, the created cache must be closed explicitly again to free resources. That makes it basically not different from the capabilities we have already.

Removing the milestone, since we don't need that at the moment. If somebody else has reasons please comment.

@cruftex
Copy link
Member Author

cruftex commented Dec 12, 2020

Properly clean timer tasks that hold a reference to the cache.
See: #167

@cruftex cruftex modified the milestones: v2.2, v2.4 Dec 12, 2020
@cruftex
Copy link
Member Author

cruftex commented Oct 14, 2021

Decided to drop this issue, since things would get very ugly and the benefit is questionable.
W.r.t. lifetime control the Cache class/interface should not have different behavior depending on the configuration. If there is a strong case for this, we can reevaluate.

@cruftex cruftex closed this as completed Oct 14, 2021
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