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 <
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,
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:
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)
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
wrote:
> Denis,
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
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