javax.cache close()

[Ognen Duzlevski]

This may not be a question for the dev list - can someone point me to a
javadoc explaining the close() method on a javax cache (and hence ignite
cache)?

I have found (in a most unpleasant way ;) that .close() on a cache closes
the cache not only for the current client using it but for everyone
(basically deletes if off the ignite cluster).

Thanks!

[dsetrakyan]

On Thu, Apr 30, 2015 at 3:27 PM, Ognen Duzlevski <[hidden email]>
wrote:

> This may not be a question for the dev list - can someone point me to a
> javadoc explaining the close() method on a javax cache (and hence ignite
> cache)?
>
> I have found (in a most unpleasant way ;) that .close() on a cache closes
> the cache not only for the current client using it but for everyone
> (basically deletes if off the ignite cluster).
>

Added this javadoc in "ignite-sprint-4" branch: Completely deletes the
cache with all its data from the system on all cluster nodes.

Should get into the next release.


>
> Thanks!
>

[Andrey Kornev]

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
    _____________________________
From: Dmitriy Setrakyan <[hidden email]>
Sent: Thursday, April 30, 2015 6:34 PM
Subject: Re: javax.cache close()
To:  <[hidden email]>


                   On Thu, Apr 30, 2015 at 3:27 PM, Ognen Duzlevski <[hidden email]>  
 wrote:  
   
 > This may not be a question for the dev list - can someone point me to a  
 > javadoc explaining the close() method on a javax cache (and hence ignite  
 > cache)?  
 >  
 > I have found (in a most unpleasant way ;) that .close() on a cache closes  
 > the cache not only for the current client using it but for everyone  
 > (basically deletes if off the ignite cluster).  
 >  
   
 Added this javadoc in "ignite-sprint-4" branch: Completely deletes the  
 cache with all its data from the system on all cluster nodes.  
   
 Should get into the next release.  
   
   
 >  
 > Thanks!  
 >

[Ognen Duzlevski]

On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <[hidden email]>
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) ;)

[Konstantin Boudnik-2]

On Fri, May 01, 2015 at 06:57AM, Ognen Duzlevski wrote:

> On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <[hidden email]>
> 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 ;)

Cos

[Branko Čibej]

On 01.05.2015 13:57, Ognen Duzlevski wrote:

> On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <[hidden email]>
> 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

[Andrey Kornev]

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: [hidden email]
> To: [hidden email]
> 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 <[hidden email]>
> > 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

     

[nivanov]

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 <[hidden email]>
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: [hidden email]
> > To: [hidden email]
> > 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 <
> [hidden email]>
> > > 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
>

[dsetrakyan]

On Fri, May 1, 2015 at 11:17 AM, Konstantin Boudnik <[hidden email]> wrote:

> On Fri, May 01, 2015 at 06:57AM, Ognen Duzlevski wrote:
> > On Fri, May 1, 2015 at 12:59 AM, Andrey Kornev <[hidden email]
> >
> > 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
>
>