Gurmehar, "I need to understand when we mean LOCK, is this lock is acquired on entire Cache or on record we are trying to update . Please clarify ." - Ignite uses record level locking.
Jay, I would avoid entire cache locks due to performance reasons, but if it's really necessary, lock object cache seems the best solution. вт, 28 дек. 2021 г. в 13:39, <jay.et...@gmx.de>: > Hi Thomas, > > > > thanks for your feedback. > > > > We originally discarded that option since it was our understanding that > this would not work as desired in a transactional context. > > > > Maybe we were wrong. Will look into it again. Thanks! > > > > Jay > > > > > > > > *From:* don.tequ...@gmx.de <don.tequ...@gmx.de> > *Sent:* Tuesday, 28 December 2021 10:59 > *To:* user@ignite.apache.org > *Subject:* Re: RE: Transactional Reader Writer Locks > > > > Instead of creating a cache with lock objects wouldn’t it be easier to use > a semaphore for each cache where you want to achieve strong reader-Writer > consistency? > > > > https://ignite.apache.org/docs/latest/data-structures/semaphore > > > > Then every time before reading/writing you acquire the semaphore first. > > > > I guess this semaphore does essentially what you’re doing manually. > > > > Regards > > Thomas. > > > > > > > > On 28.12.21 at 10:41, jay.et...@gmx.de wrote: > > And if anyone knows a different way to achieve entire-cache-locks in > Optimistic Serializable transactions: We always appreciate the help. > > > > Jay > > > > > > *From:* Gurmehar Kalra <gurmehar.ka...@hcl.com> > *Sent:* Monday, 27 December 2021 07:31 > *To:* user@ignite.apache.org; alexey.scherbak...@gmail.com > *Subject:* RE: Transactional Reader Writer Locks > > > > Hi, > > I need to understand when we mean LOCK, is this lock is acquired on entire > Cache or on record we are trying to update . > Please clarify . > > > > Regards, > > Gurmehar Singh > > > > *From:* Alexei Scherbakov <alexey.scherbak...@gmail.com> > *Sent:* 16 December 2021 22:40 > *To:* user <user@ignite.apache.org> > *Subject:* Re: Transactional Reader Writer Locks > > > > [CAUTION: This Email is from outside the Organization. Unless you trust > the sender, Don’t click links or open attachments as it may be a Phishing > email, which can steal your Information and compromise your Computer.] > > Hi. > > > > You can try OPTIMISTIC SERIALIZABLE isolation, it might have better > throughput in contending scenarios. > > But this is not the same as RW lock, because a tx can be invalidated after > a commit if a lock conflict is detected. > > No RW lock of any kind is planned, AFAIK. > > > > вт, 7 дек. 2021 г. в 23:22, <jay.et...@gmx.de>: > > Dear all, > > > > we’re running in circles with Ignite for so long now. Can anyone please > help? All our attempts to custom-build a Reader Writer Lock (/Re-entrant > Lock) for use inside transactions have failed. > > > > Background: > > - Multi-node setup > > - Very high throughput mixed read/write cache access > > - Key-Value API using transactional caches > > - Strong consistency absolute requirement > > - Transactional context required for guarantees and fault-tolerance > > > > Using Pessimistic Repeatable-Read transactions gives strong consistency > but kills performance if there’s a large number of operations on the same > cache entry (and they tend to introduce performance penalties in > entire-cache operations and difficulties in cross-cache locking as well). > All other transactional modes somehow violate the strong consistency > requirement as we see it and were able to test so far. > > > > In other distributed environments we use reader writer locks to gain both > strong consistency and high performance with mixed workloads. In Ignite > however we’re not aware that explicit locks can be used inside > transactions: The documentation clearly states so ( > https://ignite.apache.org/docs/latest/distributed-locks > <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fignite.apache.org%2Fdocs%2Flatest%2Fdistributed-locks&data=04%7C01%7Cgurmehar.kalra%40hcl.com%7Cbb66d82317d148b6221608d9c0b6ee08%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637752714176933321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1eNvAIsE5mgD6H0CSO6IX%2BSIw2nprWcQ1KX%2B5iZfwcc%3D&reserved=0>) > and trying to custom-build a reader writer lock for use inside transactions > we always end up concluding that this may not be achievable if there are > multiple ways to implicitly acquire but none to release locks. > > > > Are we out of luck here or > > - did we miss something? > > - are there workarounds you know of? > > - are there plans to implement transactional re-entrant locks in future > releases? > > > > Jay > > > > > > > > > -- > > > Best regards, > > Alexei Scherbakov > > ::DISCLAIMER:: > ------------------------------ > > The contents of this e-mail and any attachment(s) are confidential and > intended for the named recipient(s) only. E-mail transmission is not > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or may contain > viruses in transmission. The e mail and its contents (with or without > referred errors) shall therefore not attach any liability on the originator > or HCL or its affiliates. Views or opinions, if any, presented in this > email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, > dissemination, copying, disclosure, modification, distribution and / or > publication of this message without the prior written consent of authorized > representative of HCL is strictly prohibited. If you have received this > email in error please delete it and notify the sender immediately. Before > opening any email and/or attachments, please check them for viruses and > other defects. > ------------------------------ > -- Best regards, Alexei Scherbakov
