ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: Inaccurate documentation about transactions
Date Wed, 15 Feb 2017 18:50:24 GMT
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 <dmagda@apache.org> 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 <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 <
> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message