On Fri, May 1, 2015 at 11:17 AM, Konstantin Boudnik <[email protected]> wrote:
> On Fri, May 01, 2015 at 06:57AM, 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) ;) > > Agree: that'd seems to be reasonable separation of the functionality. Can > someone open the JIRA and, perhaps, contribute the patch? From my layman > standpoint - it might be one of those newbie tickets, but I've been wrong > before ;) > I would like someone from the community to confirm that if Cache.close() method does not destroy the cache, the JCache TCK still passes. If TCK still passes, I think we should make the change. > > Cos > >
