And no. I'm not describing REPEATABLE_READ. I'm describing https://en.wikipedia.org/wiki/Isolation_(database_systems)#Dirty_reads and how READ_COMMITTED isolation can avoid dirty reads.
On Wed, Jul 25, 2018 at 11:20 AM, John Wilson <sami.hailu...@gmail.com> wrote: > I agree with your description. But the documentation https:// > apacheignite.readme.io/docs/transactions is misleading in stating that no > read locks are acquired (says "READ_COMMITTED - Data is read without a lock > and is never cached in the transaction itself."). Which should be wrong. > Read locks are acquired but they are released as soon as the read is > complete (and they are not held until the transaction commits or rolls > back). > > Thanks, > > On Wed, Jul 25, 2018 at 10:33 AM, Valentin Kulichenko < > valentin.kuliche...@gmail.com> wrote: > >> 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, >> > >> > >
