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