ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wilson <sami.hailu...@gmail.com>
Subject Re: Dirty Reads and READ_COMMITTED
Date Wed, 25 Jul 2018 18:25:10 GMT
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.15@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.kulichenko@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.15@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,
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message