*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 basi
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 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 w
Hi Stephen,
good point on the performance, yes. However, I think this will not work for us
since it may give non-repeatable reads.
Image the scenario with pessimistic READ_COMMITTED:
Transaction A reads the balance of a bank account.
Now while A is still processing, Transaction B re
The Apache Ignite Community is pleased to announce the release of
Apache Ignite 2.11.1.
Apache Ignite® is a Distributed Database For High-Performance
Computing With In-Memory Speed.
https://ignite.apache.org
This is an emergency release that fixes the log4j2 dependencies.
Please check the detail
