ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Gura <ag...@apache.org>
Subject Re: Inaccurate documentation about transactions
Date Fri, 17 Feb 2017 11:35:17 GMT
>From my point of view @IgniteTransactional annotation is redundant
entity which will just confuse and lead to questions like "How to use
this annotation?" I think documention update is better way.

On Wed, Feb 15, 2017 at 1:50 PM, Evgeniy Stanilovskiy
<stanilovsky@gmail.com> wrote:
> postgres has the different viewpoint, i hope.
>
> https://www.postgresql.org/docs/9.1/static/transaction-iso.html
>
> Read Committed Isolation Level
>
> Read Committed is the default isolation level in PostgreSQL. When a
> transaction uses this isolation level, a SELECT query (without a FOR
> UPDATE/SHARE clause) sees only data committed before the query began; it
> never sees either uncommitted data or changes committed during query
> execution by concurrent transactions. In effect, a SELECT query sees a
> snapshot of the database as of the instant the query begins to run. However,
> SELECT does see the effects of previous updates executed within its own
> transaction, even though they are not yet committed.
>
>
>> Alexandr,
>>
>> If you PUT some value within transaction, this is absolutely normal that
>> you will see it on successive GET in the _same_ transaction. DIRTY_READ is
>> a different thing - it allows reads of not-yet-committed changes from
>> _another_ transaction.
>>
>> On Wed, Feb 15, 2017 at 9:41 AM, Alexandr Kuramshin <ein.nsk.ru@gmail.com>
>> wrote:
>>
>>> After doing some tests with transactions I've found transactions work not
>>> as expected after reading the documentation [1].
>>>
>>> First of all, nowhere's written which methods of the cache are
>>> transactional and which are not. Quite the contrary, after reading
>>> documentation we get know that each TRANSACTIONAL cache is fully
>>> ACID-compliant without exceptions.
>>>
>>> Only after deep multi-thread testing, and consulting with other
>>> developers,
>>> I get know that only get and put methods are running within transaction,
>>> but iterator and query methods are running outside (in autonomous)
>>> transaction with READ_COMMITTED isolation level.
>>>
>>> Later I've understood that only methods throwing
>>> TransactionTimeoutException/TransactionRollbackException/
>>> TransactionHeuristicException
>>> are fully transactional. I think all methods on page [2] should be
>>> directly
>>> described - are they transactional or not. Btw, why these exceptions are
>>> not derived from the common base class, e.g. TransactionException?
>>>
>>> Secondary, using the transactional get() method inside the READ_COMMITTED
>>> transaction we expect to get the committed value, as the documentation
>>> [1]
>>> claims:
>>>
>>> * READ_COMMITTED - Data is read without a lock and is never cached in the
>>> transaction itself.
>>>
>>> Ok, but what about put()? After doing the put() a new value, we get
>>> successive reads of the new value, that is actually DIRTY READ. Hence the
>>> value is cached within transaction. It's not documented behavior.
>>>
>>> [1] https://apacheignite.readme.io/docs/transactions
>>>
>>> [2]
>>> https://ignite.apache.org/releases/1.8.0/javadoc/org/
>>> apache/ignite/IgniteCache.html
>>>
>>> --
>>> Thanks,
>>> Alexandr Kuramshin

Mime
View raw message