In your case it’s taking locks on reads because you have REPEATABLE_READ. Couldn’t you avoid that by using READ_COMMITTED?
> On 21 Dec 2021, at 13:41, jay.et...@gmx.de wrote: > > Thanks again for the clarification Alexei. > > >>Ignite currently uses lock based concurrency control and is not well suited > >>for such a scenario > > You could still have both performance and consistency with read-heavy > workloads if explicit locking inside transactions was allowed. I’m thinking > in the direction of a ‘TransactionIsolation.Explicit’. > > Just saying... > > Best wishes and happy holidays to you all. > > Jay > > > > From: Alexei Scherbakov <alexey.scherbak...@gmail.com> > Sent: Tuesday, 21 December 2021 11:51 > To: user <user@ignite.apache.org> > Subject: Re: Transactional Reader Writer Locks > > Note, however, that until the commit happens you can still read a partial > transaction state, so the transaction logic must protect against it. > This means you shouldn't pass partial read result outside transaction scope > (like writing to external storage) until a commit has happened. > > So this basically means that in this mode all reads of an entity are > sequential, right? > No, reads can be done without blocking using OPTIMISTIC SERIALIZABLE mode. > This is the big difference with PESSIMISTIC REPEATABLE_READ mode. > > Any hints on how to solve this? > I would suggest avoiding high contention on the same key. Ignite currently > uses lock based concurrency control and is not well suited for such a > scenario. > > пн, 20 дек. 2021 г. в 17:27, <jay.et...@gmx.de <mailto:jay.et...@gmx.de>>: >> Actually, we get even worse performance with Optimistic Serializable >> transactions. Reason may be: >> >> “[..] Another important point to note here is that a transaction fails even >> if an entry was read without being modified[..],since the value of the entry >> could be important to the logic within the initiated transaction.” >> >> So this basically means that in this mode all reads of an entity are >> sequential, right? If so, it cannot help with performance when having a lot >> of reads and the need for strong consistency. >> >> >> Guys: Ignite is such an impressive product with so so many awesome >> features but effectively we have all our data in memory - and it is just >> dead-slow... >> >> >> Any hints on how to solve this? >> >> Appreciate it. >> >> Jay >> >> >> >> From: jay.et...@gmx.de <mailto:jay.et...@gmx.de> <jay.et...@gmx.de >> <mailto:jay.et...@gmx.de>> >> Sent: Friday, 17 December 2021 08:44 >> To: user@ignite.apache.org <mailto:user@ignite.apache.org> >> Subject: RE: Transactional Reader Writer Locks >> >> Hi Alexei >> >> Thanks for your note. We have actually considered optimistic transactional >> transactions before but to be honest we’re not entirely sure how to address >> this: >> >> Wiki: “When using OPTIMISTIC transactions, full read consistency can be >> achieved by disallowing potential conflicts between reads. This behavior is >> provided by OPTIMISTIC SERIALIZABLE mode. => Note, however, that until the >> commit happens you can still read a partial transaction state, so the >> transaction logic must protect against it. <=” >> >> How would a tx logic look like that protects against partial transaction >> state in optimistic serializable mode? >> >> Jay >> >> >> From: Alexei Scherbakov <alexey.scherbak...@gmail.com >> <mailto:alexey.scherbak...@gmail.com>> >> Sent: Thursday, 16 December 2021 18:10 >> To: user <user@ignite.apache.org <mailto:user@ignite.apache.org>> >> Subject: Re: Transactional Reader Writer Locks >> >> 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 <mailto: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://ignite.apache.org/docs/latest/distributed-locks>) 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 > > > > -- > > Best regards, > Alexei Scherbakov
