Thank you very much Nikolai. this is very helpful. Thanks.
On 17 March 2017 at 17:54, Nikolai Tikhonov <[email protected]> wrote: > 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
