ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Mekhanikov <dmekhani...@gmail.com>
Subject Re: Expiry policy for Cache.invoke
Date Fri, 15 Sep 2017 09:25:28 GMT
I filed a ticket for this issue:
https://issues.apache.org/jira/browse/IGNITE-6388

Also I stumbled upon another bug, trying to reproduce the previous one.
Here is a ticket: https://issues.apache.org/jira/browse/IGNITE-6389

Denis

пт, 15 сент. 2017 г. в 3:07, Valentin Kulichenko <
valentin.kulichenko@gmail.com>:

> Denis,
>
> This looks like a bug. In my understanding, getExpiryForAccess should be
> called for any update, plus one of getExpiryForCreation/getExpiryForUpdate
> depending on whether it's a new entry or not. And this definitely should
> not depend on cache mode.
>
> -Val
>
> On Thu, Sep 14, 2017 at 3:02 AM, Denis Mekhanikov <dmekhanikov@gmail.com>
> wrote:
>
> > Dmitriy,
> >
> > You are right about transactions, but the spec describes invoke, so, if
> it
> > specifies some behavior in general, then it should be followed in both
> > cases.
> >
> > Here is the most relevant part I could find in the spec:
> > https://static.javadoc.io/javax.cache/cache-api/1.0.0/
> > javax/cache/processor/EntryProcessor.html
> > I think, that if the value is loaded from CacheStore, then
> > getExpiryForCreation() should be used. Other methods should be called
> > depending on operations performed.
> >
> > Denis
> >
> > чт, 14 сент. 2017 г. в 12:02, Denis Mekhanikov <dmekhanikov@gmail.com>:
> >
> > > Val,
> > >
> > > Sorry, I may be didn't formulate the issue clearly. Other than
> predefined
> > > expiry policies (like CreatedExpiryPolicy, AccessedExpiryPolicy, etc)
> you
> > > can provide a custom expiry policy by calling
> > > setExpiryPolicyFactory(Factory<ExpiryPolicy>)
> > > <https://ignite.apache.org/releases/latest/javadoc/org/
> > apache/ignite/configuration/CacheConfiguration.html#
> > setExpiryPolicyFactory(javax.cache.configuration.Factory)>.
> > > So, cache will consult the configured ExpiryPolicy by calling
> > > getExpiryForCreation(), getExpiryForAccess() or getExpiryForUpdate(),
> > > depending on the performed operation.
> > >
> > > So, the methods of ExpiryPolicy that are called when invoke(...)
> > > <https://ignite.apache.org/releases/latest/javadoc/org/
> > apache/ignite/IgniteCache.html#invoke(K,%20org.apache.ignite.cache.
> > CacheEntryProcessor,%20java.lang.Object...)> is
> > > used, somehow depend on the configured atomicity. Of course, the
> > configured
> > > ExpiryPolicy is used, but in some cases the wrong method is called.
> > >
> > > Denis
> > >
> > > чт, 14 сент. 2017 г. в 1:54, Valentin Kulichenko <
> > > valentin.kulichenko@gmail.com>:
> > >
> > >> Denis,
> > >>
> > >> I'm confused by the issue. Do you mean that we can use expiry policy
> > other
> > >> than the one provided in configuration? How is this possible? Can you
> > >> point
> > >> to the code that implements this logic?
> > >>
> > >> -Val
> > >>
> > >> On Wed, Sep 13, 2017 at 11:29 AM, Dmitriy Setrakyan <
> > >> dsetrakyan@apache.org>
> > >> wrote:
> > >>
> > >> > Denis,
> > >> >
> > >> > I agree that the behavior should be consistent, but you will not
> find
> > >> > anything about transactions in JCache. To my knowledge, JCache does
> > not
> > >> > have transactions.
> > >> >
> > >> > I would file a ticket about the issue you found, so the community
> > could
> > >> > address it. If you are interested, perhaps you can contribute a fix
> > >> > yourself.
> > >> >
> > >> > Thanks,
> > >> > D.
> > >> >
> > >> > On Wed, Sep 13, 2017 at 5:47 AM, Denis Mekhanikov <
> > >> dmekhanikov@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > Igniters!
> > >> > >
> > >> > > I noticed a weird behavior regarding expiry policy in Ignite.
You
> > can
> > >> > find
> > >> > > an example in the attachment.
> > >> > > When you call invoke on a cache with configured CacheStore and
> > >> > > ExpiryPolicy, then chosen expiry depends on cache's atomicity
> mode.
> > >> > > If cache is atomic, then "creation" expiry timeout is chosen,
but
> if
> > >> it
> > >> > is
> > >> > > transactional - then "access".
> > >> > >
> > >> > > I think, this behavior should at least be identical in both cases,
> > but
> > >> > > what is more important, it should conform to JCache specification.
> > >> > > But I wasn't able to find a clear statement regarding this
> question
> > in
> > >> > the
> > >> > > specification. Can somebody point out a place in the specification
> > >> that
> > >> > > defines a behavior in such case?
> > >> > >
> > >> > > Cheers,
> > >> > > Denis
> > >> > >
> > >> >
> > >>
> > >
> >
>

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