*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>: > 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 <jay.et...@gmx.de> > *Sent:* Friday, 17 December 2021 08:44 > *To:* 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> > *Sent:* Thursday, 16 December 2021 18:10 > *To:* user <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>: > > 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) 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
