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 <[email protected]> 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 >
