Re: Inaccurate documentation about transactions

[Alexandr Kuramshin]

Yes, please.

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

2017-02-28 2:22 GMT+07:00 Denis Magda :

> +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 
> wrote:
>
> I like the idea of fixing the exception inheritance.
>
> On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin 
> 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 :
>>
>>> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura  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

Re: Inaccurate documentation about transactions

[Denis Magda]

+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  wrote:
> 
> I like the idea of fixing the exception inheritance.
> 
> On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin  > 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  >:
> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura  > 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
> 

Re: Inaccurate documentation about transactions

[Dmitriy Setrakyan]

I like the idea of fixing the exception inheritance.

On Mon, Feb 27, 2017 at 1:40 AM, Alexandr Kuramshin 
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 :
>
>> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura  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
>

Re: Inaccurate documentation about transactions

[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 :

> On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura  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

Re: Inaccurate documentation about transactions

[Dmitriy Setrakyan]

On Fri, Feb 17, 2017 at 3:35 AM, Andrey Gura  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.

Re: Inaccurate documentation about transactions

[Andrey Gura]

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

Re: Inaccurate documentation about transactions

[Evgeniy Stanilovskiy]

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  


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

Re: Inaccurate documentation about transactions

[Denis Magda]

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  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  > 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
>> > 
>>> 
>> 
>>> 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 
>> 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 > 
>> releases/1.8.0/javadoc/org/apache/ignite/IgniteCache.html>
>>> 
>>> --
>>> Thanks,
>>> Alexandr Kuramshin

Re: Inaccurate documentation about transactions

[Dmitriy Setrakyan]

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  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
>  >
>
> >  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 
> 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  releases/1.8.0/javadoc/org/apache/ignite/IgniteCache.html>
> >
> > --
> > Thanks,
> > Alexandr Kuramshin
>
>

Re: Inaccurate documentation about transactions

[Denis Magda]

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 


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

Re: Inaccurate documentation about transactions

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

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