ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikita Ivanov <nivano...@gmail.com>
Subject Re: javax.cache close()
Date Sat, 02 May 2015 22:13:30 GMT
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 <andrewkornev@hotmail.com>
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: brane@apache.org
> > To: dev@ignite.incubator.apache.org
> > 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 <
> andrewkornev@hotmail.com>
> > > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message