Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMP9FTTgBfMzB58FixRbfT4QJ8TFykkp1mC8xk0xAbvcuEq3jg@mail.gmail.com>
References: <CAMP9FTQ_RL3O6MojT4wZejj3ojDue4Yfkc5v97b-OMimK+hUMw@mail.gmail.com>
 <CA+0=VoXUmgSCCoqP8=A0hMqXzF4ynzzKgyQp4Vj0zrEmbXB7sQ@mail.gmail.com>
 <CABuYRcpvOkST1jfy46YXJA4Cjpni1-OHDmo=p66E_uWY6MqHfg@mail.gmail.com>
 <CAMP9FTQMx0RtJtEDCF9FPNTzQKki3n8WOGzD1C43v5S3Cgd6UQ@mail.gmail.com> <CAMP9FTTgBfMzB58FixRbfT4QJ8TFykkp1mC8xk0xAbvcuEq3jg@mail.gmail.com>
From: Valentin Kulichenko <valentin.kulichenko@gmail.com>
Date: Thu, 14 Sep 2017 17:07:22 -0700
Message-ID: <CABuYRcrzPKRMuNjJzzXSayEmm475QrYxkSW7tNmGPROw+vrqwA@mail.gmail.com>
Subject: Re: Expiry policy for Cache.invoke
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary="001a113ed6be2d4ce405592f2f55"
archived-at: Fri, 15 Sep 2017 00:07:59 -0000

--001a113ed6be2d4ce405592f2f55
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 i=
t
> 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
>
> =D1=87=D1=82, 14 =D1=81=D0=B5=D0=BD=D1=82. 2017 =D0=B3. =D0=B2 12:02, Den=
is Mekhanikov <dmekhanikov@gmail.com>:
>
> > Val,
> >
> > Sorry, I may be didn't formulate the issue clearly. Other than predefin=
ed
> > expiry policies (like CreatedExpiryPolicy, AccessedExpiryPolicy, etc) y=
ou
> > 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
> >
> > =D1=87=D1=82, 14 =D1=81=D0=B5=D0=BD=D1=82. 2017 =D0=B3. =D0=B2 1:54, Va=
lentin 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 fin=
d
> >> > 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 questio=
n
> in
> >> > the
> >> > > specification. Can somebody point out a place in the specification
> >> that
> >> > > defines a behavior in such case?
> >> > >
> >> > > Cheers,
> >> > > Denis
> >> > >
> >> >
> >>
> >
>

--001a113ed6be2d4ce405592f2f55--