ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolai Tikhonov <ntikho...@apache.org>
Subject Re: Lock and Transaction
Date Fri, 17 Mar 2017 12:24:14 GMT
Yes Ignite transaction allows to avoid inconsistency. Also it's mean that
you don't need to do extra work, Ignite will do it. :) When you using
IgniteCache#lock, this is similar us you try to implement your own
transactions, but in your case it not needed. Let's allows to Ignite does
it. When you using ignite Transaction API it's allows you to tweak
configuration for getting best performance. If you are sure that operation
by person has low contention that you can using OPTIMISTIC transactions and
get better performance otherwise you can choose PESSIMISTIC transaction.
Explicit locks don't provide this ability. Also Ignite transaction have
deadlock detection mechanism that very useful for fixing lock conflicts. In
my opinion that transactions better then explicite locks in 99% cases.

Thanks,
Nikolay

On Fri, Mar 17, 2017 at 3:02 PM, Anil <anilklce@gmail.com> wrote:

> Hi Nikolai,
>
> thanks.
>
> You mean personCache.get(personId); inside transaction would avoid
> concurrent access for person id entries in both person cache and detail
> cache ?
>
> Thanks.
>
> On 17 March 2017 at 17:24, Nikolai Tikhonov <ntikhonov@apache.org> wrote:
>
>> Anil,
>>
>> You can just enlisted entry with personId in transaction and you don't
>> need to use explicit lock.
>>
>> personCache = ignite.cache("PERSON_CACHE");
>> detailCache = ignite.cache("DETAIL_CACHE");
>>
>> try (Transaction tx = ignite.transactions().txStart(PESSIMISTIC,
>> REPEATABLE_READ)) {
>>     // On this step will be acquired lock on personId
>>     // and only one thread in grid will execute code bellow.
>>     personCache.get(personId);
>>     detailCache.put(...)
>>
>>     // cache put,remove,invoke and etc.
>>     tx.commit();
>> }
>>
>> Ignite cross-cache transactions has ACID guarantee. I would recommend use
>> this approach.
>>
>> On Fri, Mar 17, 2017 at 2:49 PM, Anil <anilklce@gmail.com> wrote:
>>
>>> Hi Nikolai,
>>>
>>> I need to perform cross cache updates in case of person message and
>>> detail message from kafka.
>>>
>>> that cross cache updates happens based on person Id which is person
>>> cache key. I am using explicit lock on person cache for personId and
>>> avoiding the parallel cross cache operations for the same person id.
>>>
>>> Please let me know if you have any questions. thanks.
>>>
>>> On 17 March 2017 at 15:30, Nikolai Tikhonov <ntikhonov@apache.org>
>>> wrote:
>>>
>>>> Hi Anil!
>>>>
>>>> Ignite Transaction API allowed to achieve your requirements. It's allow
>>>> to avoid using explicit lock. Could you describe why do you need use
>>>> explicit lock in your case?
>>>>
>>>> On Fri, Mar 17, 2017 at 6:46 AM, Anil <anilklce@gmail.com> wrote:
>>>>
>>>>> Hi Nikolai,
>>>>>
>>>>> Thanks for response. in my usecase, i need to control incoming
>>>>> messages so that no two messages of personId process in parallel. i believe
>>>>> this can achieved with both explicit locks and entry processor.
>>>>>
>>>>> Can entryprocessor support cross cache atomicity ?
>>>>>
>>>>> Thanks
>>>>>
>>>>> On 17 March 2017 at 01:29, Nikolai Tikhonov <ntikhonov@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Anil,
>>>>>>
>>>>>> Yes, you're right that atomic cache doesn't support explicit locks.
>>>>>>
>>>>>> >I am not sure how entryprocessor invoke behaves in my case. if
it
>>>>>> is single cache update, that is straight forward. and not sure about
>>>>>> transaction for 2-3 operations for 2 caches.
>>>>>> EntryProcessor modifies (update/remove/create) only one entry.
>>>>>>
>>>>>> >I do 2 to 3 updates/puts between two caches like updating parent
>>>>>> person info to child person and creating empty detail info by checking
>>>>>> detail cache.
>>>>>> Ignite supports cross-cache transactions (one transaction can update
>>>>>> to several caches) with support ACID . I think that this feature
will be
>>>>>> helpful for your.
>>>>>>
>>>>>> On Thu, Mar 16, 2017 at 8:20 PM, Anil <anilklce@gmail.com>
wrote:
>>>>>>
>>>>>>> Hi Nikolai,
>>>>>>>
>>>>>>> Thanks for response.
>>>>>>>
>>>>>>> Distributed locks wont work for atomic caches. correct ? if i
>>>>>>> remember it correclty, i see an exception sometime back and then
i used
>>>>>>> transcational.
>>>>>>>
>>>>>>> I do 2 to 3 updates/puts between two caches like updating parent
>>>>>>> person info to child person and creating empty detail info by
checking
>>>>>>> detail cache.
>>>>>>>
>>>>>>> I am not sure how entryprocessor invoke behaves in my case. if
it is
>>>>>>> single cache update, that is straight forward. and not sure about
>>>>>>> transaction for 2-3 operations for 2 caches.
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> On 16 March 2017 at 22:43, Nikolai Tikhonov <ntikhonov@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> If your update logic does not contains heavy operations (locks,
>>>>>>>> cache puts and etc) and how I see from your comment above
this is true you
>>>>>>>> can use IgniteCache#invoke [1]. The method provides needed
you garanty.
>>>>>>>> Also you can change cache mode to ATOMIC for better perfomance.
>>>>>>>>
>>>>>>>> 1. https://apacheignite.readme.io/docs/jcache#section-entryp
>>>>>>>> rocessor
>>>>>>>>
>>>>>>>> On Thu, Mar 16, 2017 at 7:55 PM, Anil <anilklce@gmail.com>
wrote:
>>>>>>>>
>>>>>>>>> Hi Nikolai,
>>>>>>>>>
>>>>>>>>> No. person message and detail message can be executed
by different
>>>>>>>>> nodes and both messages executes different logics.
>>>>>>>>>
>>>>>>>>> *Person message* - will update/create person entry into
person
>>>>>>>>> cache and check the if any detail entry is available
or not in detail
>>>>>>>>> cache. if exists, updates person info to detail entry.
if not, creates
>>>>>>>>> empty detail entry
>>>>>>>>> *Detail Message* - will check empty detail entry is availble
or
>>>>>>>>> not. if yes, delete and create new detail entry with
personal info. else
>>>>>>>>> creates/updates the entry.
>>>>>>>>>
>>>>>>>>> To avoid data inconsistency, i created lock on person
id so
>>>>>>>>> messages (person and detail) of person id wont run in
parallel.
>>>>>>>>>
>>>>>>>>> now, i am trying to achieve atomicity for each message
operations.
>>>>>>>>> Hope this is clear.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> On 16 March 2017 at 22:12, Nikolai Tikhonov <ntikhonov@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Anil!
>>>>>>>>>>
>>>>>>>>>> If I understood correctly (you need to perform operations
on two
>>>>>>>>>> caches have exclusive lock on personId) then in your
case the better way is
>>>>>>>>>> using Ignite pessimistic transaction:
>>>>>>>>>>
>>>>>>>>>> personCache = ignite.cache("PERSON_CACHE");
>>>>>>>>>> detailCache = ignite.cache("DETAIL_CACHE");
>>>>>>>>>>
>>>>>>>>>> try (Transaction tx = ignite.transactions().txStart(PESSIMISTIC,
>>>>>>>>>> REPEATABLE_READ)) {
>>>>>>>>>>     // On this step will be acquired lock on personId
>>>>>>>>>>     // and only one thread in grid will execute code
bellow.
>>>>>>>>>>     personCache.get(personId);
>>>>>>>>>>
>>>>>>>>>>     // cache put,remove,invoke and etc.
>>>>>>>>>>     tx.commit();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Is't work for you?
>>>>>>>>>>
>>>>>>>>>> On Thu, Mar 16, 2017 at 3:09 PM, Anil <anilklce@gmail.com>
wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I need to make sure that entries are added correctly
in two
>>>>>>>>>>> caches.
>>>>>>>>>>>
>>>>>>>>>>> I have two caches  Person and Detail. personId
is the key for
>>>>>>>>>>> Person cache and detailedId is the key for Detail
cache.
>>>>>>>>>>>
>>>>>>>>>>> Each Detail cache entry would have some information
of Person
>>>>>>>>>>> cache entry based on personId. and i am adding
entries to caches using
>>>>>>>>>>> Kafka.
>>>>>>>>>>>
>>>>>>>>>>> When Person and Detail messages are processed,
order cannot be
>>>>>>>>>>> maintained and processed by different nodes.
So to avoid data inconsistency
>>>>>>>>>>> issues - i did following.
>>>>>>>>>>>
>>>>>>>>>>> *Person message :*
>>>>>>>>>>>
>>>>>>>>>>> Locl lock = personCache.lock(personId);
>>>>>>>>>>> lock.lock();
>>>>>>>>>>>
>>>>>>>>>>> // update person operations for both person cache
and detail
>>>>>>>>>>> cache
>>>>>>>>>>>
>>>>>>>>>>> lock.unlock();
>>>>>>>>>>>
>>>>>>>>>>> *Detail Mesage :*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Locl lock = detailCache.lock(personId);  // person
id from
>>>>>>>>>>> detail message
>>>>>>>>>>> lock.lock();
>>>>>>>>>>>
>>>>>>>>>>> // update person operations for both person cache
and detail
>>>>>>>>>>> cache
>>>>>>>>>>>
>>>>>>>>>>> lock.unlock();
>>>>>>>>>>>
>>>>>>>>>>> with this, till one of the message processed
for same person Id,
>>>>>>>>>>> other would not acquire lock.
>>>>>>>>>>>
>>>>>>>>>>> now how to maintain the ACID for update operations
? ignite
>>>>>>>>>>> transactions does not work inside lock. Is there
anyway to achieve the
>>>>>>>>>>> above usecase with ACID ?
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message