Alexander, Thanks for extensive feedback. I do support your idea that we need to specify explicitly which methods are transactional and which aren’t.
> 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. As far as I know, a family of “invoke” methods is also fully transactional. As for SQL queries we state loud and clear that they’re non transactional at the moment: https://apacheignite.readme.io/docs/sql-queries#section-transactional-sql <https://apacheignite.readme.io/docs/sql-queries#section-transactional-sql> > 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? Agree. Could you label all the methods at Java Doc layer and send it for review to the community? Once the review has been passed I’ll update the readmeio documentation. — Denis > On Feb 14, 2017, at 10:41 PM, 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 > <https://apacheignite.readme.io/docs/transactions> > > [2] > https://ignite.apache.org/releases/1.8.0/javadoc/org/apache/ignite/IgniteCache.html > > <https://ignite.apache.org/releases/1.8.0/javadoc/org/apache/ignite/IgniteCache.html> > > -- > Thanks, > Alexandr Kuramshin
