This is even better. Alexandr, could you do this since you already know what’s transaction and what isn’t?
— Denis > On Feb 15, 2017, at 10:50 AM, Dmitriy Setrakyan <[email protected]> wrote: > > Why not just have @IgniteTransactional annotation and attach it to all the > transactional methods? > > On Wed, Feb 15, 2017 at 9:48 AM, Denis Magda <[email protected] > <mailto:[email protected]>> wrote: > >> 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 >> <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 >> <https://apacheignite.readme.io/docs/transactions>> >>> >>> [2] https://ignite.apache.org/releases/1.8.0/javadoc/org/ >>> <https://ignite.apache.org/releases/1.8.0/javadoc/org/> >> apache/ignite/IgniteCache.html <https://ignite.apache.org/ >> <https://ignite.apache.org/> >> releases/1.8.0/javadoc/org/apache/ignite/IgniteCache.html> >>> >>> -- >>> Thanks, >>> Alexandr Kuramshin
