Hi John,
Read committed isolation typically implies that lock on read is not held
throughout the transaction lifecycle, i.e. released right after read is
completed (in Ignite this just means that no lock is required at all). This
semantic allows second read to get an updated value that was already
committed by another transaction. See Wikipedia description for example:
https://en.wikipedia.org/wiki/Isolation_(database_systems)#Read_committed
What you're describing is REPEATABLE_READ isolation which guarantees that
subsequent reads return the same value. In Ignite it's achieved by
acquiring lock on read and releasing it only on commit/rollback.
-Val
On Wed, Jul 25, 2018 at 10:12 AM John Wilson <sami.hailu...@gmail.com>
wrote:
> Hi,
>
> Consider the following transaction where we read key 1 twice.
>
> try (Transaction tx = Ignition.ignite().transactions().txStart(PESSIMISTIC,
> READ_COMMITTED)) {
> cache.get(1);
> //...
> cache.get(1);
> tx.commit();
> }
>
> According to the documentation here,
> https://apacheignite.readme.io/docs/transactions, data is read without a
> lock and is never cached. If that is the case, then how do we avoid a dirty
> read on the second cache.get(1)? Another uncommitted transaction may update
> the key between the first and second reads.
>
> In most RDMS, a READ_COMMITTED isolation level, acquires locks for both
> read and writes. The read lock is released after a read while the write
> lock is held until the transaction completes. So for the above example, I
> expect a read lock on each cache.get(1).
>
>
> Thanks,
>
