Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[Evans Ye]

I'm not quite sure this is relevant to your issue.
I've experienced the hanging issue on ignite 1.8.0 when topology changed.
https://issues.apache.org/jira/browse/IGNITE-4450 might get to fix the
problem.
FYR.


2017-03-16 1:03 GMT+08:00 bintisepaha :

> Andrey, do you think topology changes with client nodes (not server nodes)
> leaving and joining the cluster may have any impact on transaction?
>
> twice out of the 4 times we saw topology changes while the last successful
> update was done to the key that was eventually locked.
>
> Yesterday we saw this same issue on another cache. We are due for 1.8
> upgrade soon, but given that no one else has seen this issue before, we are
> not sure if 1.8 would have fixed it either.
>
> Let us know what you think.
>
> Thanks,
> Binti
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Pessimistic-TXN-did-not-release-lock-on-a-key-all-
> subsequent-txns-failed-tp10536p11203.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: Ignite for fine-grained policy/quota control

[Evans Ye]

I have considered using AtomicLong as well. But the main reason to
introduce ignite lock is becuase the increaseAndGet() method should only be
called after all the policies are allowed.

Here is an example, when a message is allowed by Policy A(100 messages per
user per day), but blocked by policy B(500 messages per user per week),
nether counter A and counter B should have count increased.

Hence, my thought using ignite lock:
1). lock all used keys in policies
2). exam policies
3). If allowed, update counters
4). Unlock all used keys

Would transaction help in my case?

vkulichenko 於 2017年2月13日 週一，上午10:33寫道：

> Hi Evans,
>
>
>
> It sounds like you can simply use AtomicLong:
>
> https://apacheignite.readme.io/docs/atomic-types
>
>
>
> -Val
>
>
>
>
>
>
>
> --
>
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-for-fine-grained-policy-quota-control-tp10563p10584.html
>
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
>

Ignite for fine-grained policy/quota control

[Evans Ye]

Hi Igniters,

We recently are using Ignite building a real-time notification system.
Ignite plays a crucial part on policy control for notifications. For
example, we would like a user who has a quota of 100 notifications per day
gets 100 messages per day precisely. Once quota exceeded, Further
notifications should be dropped.

The way we are trying to implement this is to use IgniteCache with the key
to be user id and the value to be a counter. Since the system is
distributed, we also adopt Ignite distributed lock to make sure every
read/write on the counter(quota) is correct.

Do you think this is the right way to use Ignite, or there are better
solutions?

Best,
Evans Ye