I may have missed that - but did anyone suggest to simply document the current incorrect behaviour?!? Of course, it has to be fixed according to spec...
-- Nikita Ivanov On Sat, May 2, 2015 at 2:18 PM, Andrey Kornev <[email protected]> wrote: > 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 >
