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.kuliche...@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 <dmekhani...@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 <dmekhani...@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.kuliche...@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 < > > >> dsetrak...@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 < > > >> dmekhani...@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 > > >> > > > > >> > > > >> > > > > > >
