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: <mailto:jay.et...@gmx.de> jay.et...@gmx.de < <mailto:jay.et...@gmx.de> jay.et...@gmx.de> Sent: Friday, 17 December 2021 08:44 To: <mailto:user@ignite.apache.org> 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 < <mailto:alexey.scherbak...@gmail.com> alexey.scherbak...@gmail.com> Sent: Thursday, 16 December 2021 18:10 To: user < <mailto:user@ignite.apache.org> 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
