In the spirit of the principle of least surprise, the Cache.close() should have non-destructive semantics and only do what the spec's section 4.1.6 says it should:
"close and release all resources being coordinated on behalf of the Cache by the CacheManager. This includes calling the close method on configured CacheLoader, CacheWriter, registered CacheEntryListeners and ExpiryPolicy instances that implement the java.io.Closeable interface". And as Brane has said, no amount documentation will prevent people from making the same mistake if the close() implementation is left as is now. Regards Andrey > Date: Fri, 1 May 2015 21:17:19 +0200 > From: [email protected] > To: [email protected] > Subject: Re: javax.cache close() > > On 01.05.2015 13:57, Ognen Duzlevski wrote: > > On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <[email protected]> > > wrote: > > > >> Dmitriy, > >> It seems the JCache spec doesn't explicitly require the cache data to be > >> destroyed by a Cache.close() call. See page 38. > >> The way I interpret (perhaps incorrectly) the semantics on the close() is > >> more like closing of an OS file: all data structures and buffers allocated > >> and managed by the OS kernel on behalf of an application get released, but > >> the file and its data are still there. It's just the application no longer > >> holds a handle to it... > >> Essentially, Cache.close() closes a specific *instance* of the cache > >> class. That instance becomes unusable from this moment on, but other > >> instances of the Cache class for the same named cache may still be alive > >> and kickin'.According to the spec to actually destroy the cache and its > >> data one should use CacheManager.destroyCache(cacheName) > >> instead.RegardsAndrey > >> > > Andrey, hah, that was exactly my expectation. Imagine my surprise when I > > found out that a client app I wrote obliterated a multi Gb+ cache in one > > operation (close) ;) > > Yeah, that really violates the principle of least surprise. No amount of > javadoc explanations can fix that ... I'd categorize this as an API > implementation bug. > > -- Brane
