Ignite Transaction with Locks but not SERIALIZABLE user case.

[bingili <bi...@illinois.edu>]

Hello, 

I have some operations which does not care about the order, e.g., each
operation is to increase the key value by 1 or decrease by 1. 

So I need a lock to protect each key on read and write. Also I need to put
operations in transaction, since ignite will handle the commit and rollback. 

Put them together, I found that Pessimistic Transactions seems to work for
this user case, but SERIALIZABLE is too strict on this case. For my user
case, It is OK to interleave between transactions as long as read/write
protection on each overlapping key between concurrent transactions. I do not
need SERIALIZABLE since that will degrade my throughput.


May I know if there is a better way to handle this user case, please?
Hope my question is clear.


Regards.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite Transaction with Locks but not SERIALIZABLE user case.

[afedotov <al...@gmail.com>]

Hello,

increment/decrement is a read-modify-write operation, so to achieve the
desired behavior
you need to lock the key and perform the operation under that lock. So you
need to use
a transaction mode and isolation level that meet the requirements.

For this case, you could use the approach described here.
https://apacheignite.readme.io/docs/jcache#section-entryprocessor.
As well PESSIMISTIC REPEATABLE_READ/SERIALIZABLE should work too
https://apacheignite.readme.io/docs/transactions#section-pessimistic-transactions.

If you anticipate that increment/decrement operation contention won't be
very high, then you could try
OPTIMISTIC SERIALIZABLE and handle TransactionOptimisticException as
described here
https://apacheignite.readme.io/docs/transactions#section-optimistic-transactions

Kind regards,
Alex



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/