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]> 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 > > > > > 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 > >
