Inaccurate documentation about transactions

[Alexandr Kuramshin]

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

[Vladimir Ozerov]

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

[Evgeniy Stanilovskiy-2]

postgres has the different viewpoint, i hope.

https://www.postgresql.org/docs/9.1/static/transaction-iso.html

Read Committed Isolation Level

Read Committed is the default isolation level in PostgreSQL. When a  
transaction uses this isolation level, a SELECT query (without a FOR  
UPDATE/SHARE clause) sees only data committed before the query began; it  
never sees either uncommitted data or changes committed during query  
execution by concurrent transactions. In effect, a SELECT query sees a  
snapshot of the database as of the instant the query begins to run.  
However, SELECT does see the effects of previous updates executed within  
its own transaction, even though they are not yet committed.

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

[dmagda]

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

[dsetrakyan]

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

[dmagda]

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]>
>> 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

[agura]

From my point of view @IgniteTransactional annotation is redundant
entity which will just confuse and lead to questions like "How to use
this annotation?" I think documention update is better way.

On Wed, Feb 15, 2017 at 1:50 PM, Evgeniy Stanilovskiy
<[hidden email]> wrote:

> postgres has the different viewpoint, i hope.
>
> https://www.postgresql.org/docs/9.1/static/transaction-iso.html
>
> Read Committed Isolation Level
>
> Read Committed is the default isolation level in PostgreSQL. When a
> transaction uses this isolation level, a SELECT query (without a FOR
> UPDATE/SHARE clause) sees only data committed before the query began; it
> never sees either uncommitted data or changes committed during query
> execution by concurrent transactions. In effect, a SELECT query sees a
> snapshot of the database as of the instant the query begins to run. However,
> SELECT does see the effects of previous updates executed within its own
> transaction, even though they are not yet committed.
>
>
>> 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 <[hidden email]>
>> 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

[dsetrakyan]

On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura <[hidden email]> wrote:

> From my point of view @IgniteTransactional annotation is redundant
> entity which will just confuse and lead to questions like "How to use
> this annotation?" I think documention update is better way.
>

Why do you think it will be confusing? This annotation is suggested purely
for documentation purposes, nothing else. Instead of adding documentation
to every method, we just add the annotation. User can check the
@IgniteTransactional javadoc to understand what this annotation means.

[Alexandr Kuramshin]

I think annotating the methods with @IgniteTransactional is redundant,
because they are already marked by "throws
TransactionTimeoutException/TransactionRollbackException/TransactionHeuristicException".

For example, the same approach was used in JavaBeans 1.01 specs [1] with
TooManyListenersException.

The only thing I'd like to do: make all
TransactionTimeoutException/TransactionRollbackException/TransactionHeuristicException
are derived from the same parent TransactionException. And declare all
transactional methods as "throws TransactionException" with consequent
Javadoc update.

[1]
http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/

2017-02-18 1:07 GMT+07:00 Dmitriy Setrakyan <[hidden email]>:

> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura <[hidden email]> wrote:
>
> > From my point of view @IgniteTransactional annotation is redundant
> > entity which will just confuse and lead to questions like "How to use
> > this annotation?" I think documention update is better way.
> >
>
> Why do you think it will be confusing? This annotation is suggested purely
> for documentation purposes, nothing else. Instead of adding documentation
> to every method, we just add the annotation. User can check the
> @IgniteTransactional javadoc to understand what this annotation means.
>

--
Thanks,
Alexandr Kuramshin

[dsetrakyan]

I like the idea of fixing the exception inheritance.

On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin <[hidden email]>
wrote:

> I think annotating the methods with @IgniteTransactional is redundant,
> because they are already marked by "throws TransactionTimeoutException/
> TransactionRollbackException/TransactionHeuristicException".
>
> For example, the same approach was used in JavaBeans 1.01 specs [1] with
> TooManyListenersException.
>
> The only thing I'd like to do: make all TransactionTimeoutException/
> TransactionRollbackException/TransactionHeuristicException are derived
> from the same parent TransactionException. And declare all transactional
> methods as "throws TransactionException" with consequent Javadoc update.
>
> [1] http://download.oracle.com/otndocs/jcp/7224-
> javabeans-1.01-fr-spec-oth-JSpec/
>
> 2017-02-18 1:07 GMT+07:00 Dmitriy Setrakyan <[hidden email]>:
>
>> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura <[hidden email]> wrote:
>>
>> > From my point of view @IgniteTransactional annotation is redundant
>> > entity which will just confuse and lead to questions like "How to use
>> > this annotation?" I think documention update is better way.
>> >
>>
>> Why do you think it will be confusing? This annotation is suggested purely
>> for documentation purposes, nothing else. Instead of adding documentation
>> to every method, we just add the annotation. User can check the
>> @IgniteTransactional javadoc to understand what this annotation means.
>>
>
>
>
> --
> Thanks,
> Alexandr Kuramshin
>

[dmagda]

+1 to Alexander’s proposal.

Alexander, could you wrap the discussion up creating a ticket with detailed explanation what to do?

—
Denis

> On Feb 27, 2017, at 9:01 AM, Dmitriy Setrakyan <[hidden email]> wrote:
>
> I like the idea of fixing the exception inheritance.
>
> On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin <[hidden email] <mailto:[hidden email]>> wrote:
> I think annotating the methods with @IgniteTransactional is redundant, because they are already marked by "throws TransactionTimeoutException/TransactionRollbackException/TransactionHeuristicException".
>
> For example, the same approach was used in JavaBeans 1.01 specs [1] with TooManyListenersException.
>
> The only thing I'd like to do: make all TransactionTimeoutException/TransactionRollbackException/TransactionHeuristicException are derived from the same parent TransactionException. And declare all transactional methods as "throws TransactionException" with consequent Javadoc update.
>
> [1] http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/ <http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/>
>
> 2017-02-18 1:07 GMT+07:00 Dmitriy Setrakyan <[hidden email] <mailto:[hidden email]>>:
> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura <[hidden email] <mailto:[hidden email]>> wrote:
>
> > From my point of view @IgniteTransactional annotation is redundant
> > entity which will just confuse and lead to questions like "How to use
> > this annotation?" I think documention update is better way.
> >
>
> Why do you think it will be confusing? This annotation is suggested purely
> for documentation purposes, nothing else. Instead of adding documentation
> to every method, we just add the annotation. User can check the
> @IgniteTransactional javadoc to understand what this annotation means.
>
>
>
> --
> Thanks,
> Alexandr Kuramshin
>

[Alexandr Kuramshin]

Yes, please.

https://issues.apache.org/jira/browse/IGNITE-4795

2017-02-28 2:22 GMT+07:00 Denis Magda <[hidden email]>:

> +1 to Alexander’s proposal.
>
> Alexander, could you wrap the discussion up creating a ticket with
> detailed explanation what to do?
>
> —
> Denis
>
> On Feb 27, 2017, at 9:01 AM, Dmitriy Setrakyan <[hidden email]>
> wrote:
>
> I like the idea of fixing the exception inheritance.
>
> On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin <[hidden email]>
> wrote:
>
>> I think annotating the methods with @IgniteTransactional is redundant,
>> because they are already marked by "throws TransactionTimeoutException/Tr
>> ansactionRollbackException/TransactionHeuristicException".
>>
>> For example, the same approach was used in JavaBeans 1.01 specs [1] with
>> TooManyListenersException.
>>
>> The only thing I'd like to do: make all TransactionTimeoutException/Tr
>> ansactionRollbackException/TransactionHeuristicException are derived
>> from the same parent TransactionException. And declare all transactional
>> methods as "throws TransactionException" with consequent Javadoc update.
>>
>> [1] http://download.oracle.com/otndocs/jcp/7224-javabeans-1.
>> 01-fr-spec-oth-JSpec/
>>
>> 2017-02-18 1:07 GMT+07:00 Dmitriy Setrakyan <[hidden email]>:
>>
>>> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura <[hidden email]> wrote:
>>>
>>> > From my point of view @IgniteTransactional annotation is redundant
>>> > entity which will just confuse and lead to questions like "How to use
>>> > this annotation?" I think documention update is better way.
>>> >
>>>
>>> Why do you think it will be confusing? This annotation is suggested
>>> purely
>>> for documentation purposes, nothing else. Instead of adding documentation
>>> to every method, we just add the annotation. User can check the
>>> @IgniteTransactional javadoc to understand what this annotation means.
>>>
>>
>>
>>
>> --
>> Thanks,
>> Alexandr Kuramshin
>>
>
>
>

--
Thanks,
Alexandr Kuramshin