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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>>>> 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 <[email protected]> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
