ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anil <anilk...@gmail.com>
Subject Re: Lock and Transaction
Date Fri, 17 Mar 2017 12:02:25 GMT
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-entryprocessor
>>>>>>>
>>>>>>> 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