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 > > > > > >
