[jira] [Created] (IGNITE-13556) .NET: Thin client: Transactions support async

[Sergey Stronchinskiy (Jira)]

Sergey Stronchinskiy created IGNITE-13556:
-

 Summary: .NET: Thin client: Transactions support async
 Key: IGNITE-13556
 URL: https://issues.apache.org/jira/browse/IGNITE-13556
 Project: Ignite
  Issue Type: Improvement
  Components: platforms, thin client
Affects Versions: 2.10
Reporter: Sergey Stronchinskiy


Currently are handled via `ThreadLocal` which does not support async flow.   



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Cpp thin client transactions support ready for review.

[Zhenya Stanilovsky]

Thanks for all who participated in review.
Cpp transactions functionality already in master.
Appropriate wiki page [1] was updated.
 
[1] https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features
 
>
>
>Great, I'll take a look.
>
>Best Regards,
>Igor
>
>
>On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky
>< arzamas...@mail.ru.invalid > wrote:
>
>>
>>
>> Thanks Ivan Daschinsky for review, does anyone more who could check it ?
>>
>> thanks !
>> >Igniters, seems i complete with transactions in thin cpp client
>> >implementation [1], part of iep-34 [2].
>> >Can anyone review my decision ?
>> >Failed test seems not mine, looks like after fresh master rebase it will
>> >gone.
>> >
>> >[1]  https://issues.apache.org/jira/browse/IGNITE-13308
>> >[2]
>> >
>>  
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> >
>> >
>> >
>>
>>
>> 
 
 
 
 

Re: Cpp thin client transactions support ready for review.

[Igor Sapego]

Great, I'll take a look.

Best Regards,
Igor


On Mon, Aug 24, 2020 at 8:33 AM Zhenya Stanilovsky
 wrote:

>
>
> Thanks Ivan Daschinsky for review, does anyone more who could check it ?
>
> thanks !
> >Igniters, seems i complete with transactions in thin cpp client
> >implementation [1], part of iep-34 [2].
> >Can anyone review my decision ?
> >Failed test seems not mine, looks like after fresh master rebase it will
> >gone.
> >
> >[1]  https://issues.apache.org/jira/browse/IGNITE-13308
> >[2]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> >
> >
>
>
>
>

Cpp thin client transactions support ready for review.

[Zhenya Stanilovsky]

Thanks Ivan Daschinsky for review, does anyone more who could check it ? 
 
thanks !
>Igniters, seems i complete with transactions in thin cpp client
>implementation [1], part of iep-34 [2].
>Can anyone review my decision ?
>Failed test seems not mine, looks like after fresh master rebase it will
>gone.
>
>[1]  https://issues.apache.org/jira/browse/IGNITE-13308
>[2]
>https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
>
>  
 
 
 
 

Cpp thin client transactions support ready for review.

[Zhenya Stanilovsky]

 
Igniters, seems i complete with transactions in thin cpp client implementation 
[1], part of iep-34 [2].
Can anyone review my decision ?
Failed test seems not mine, looks like after fresh master rebase it will gone.
 
[1]  https://issues.apache.org/jira/browse/IGNITE-13308
[2] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
 
 
 

Re: Thin client: transactions support

[Pavel Tupitsyn]

Alex, thank you, I'm convinced now, no objections
to ThinClientConfiguration.

On Wed, Aug 28, 2019 at 12:59 PM Alex Plehanov 
wrote:

> Pavel, we already have OdbcEnabled, JdbcEnabled and ThinClientEnabled
> properties inside ClientConnectorConfiguration. ThinClientEnabled=false
> does not assume that JDBC thin client is disabled, it's clear and not
> confusing. I'm not agreed that the same situation with
> ThinClientConfiguration will be confusing, the same logic works here as for
> ThinClientEnabled flag. At least we can add JavaDoc that this configuration
> is not related to JDBC and ODBC, but I think it's redundant.
>
> ср, 28 авг. 2019 г. в 12:41, Pavel Tupitsyn :
>
> > ThinClientConfiguration name is very confusing in existing situation.
> > E.g. does it apply to JDBC Thin Client? No, it does not, but it is easy
> to
> > assume it does.
> >
> > On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov 
> > wrote:
> >
> > > Ilya, Igor,
> > >
> > > Nested property is what exactly I've done in the last fix.
> > > ClientConnectorConfiguration now includes ThinClientConfiguration which
> > > contain only one property MaxActiveTxPerConnection for now.
> > >
> > > Pavel,
> > >
> > > Why do you think that nested ThinClientConfiguration is more confusing
> > than
> > > property in common configuration which related only to part of
> > configurable
> > > elements? In case of nested configuration, user will know that property
> > is
> > > related only to thin client even without reference to JavaDoc.
> > > Now it's only one such property, but if continue to introduce specific
> > > properties to the common configuration in the future, after a while
> there
> > > will be a mess.
> > >
> > >
> > > вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >:
> > >
> > > > Hello!
> > > >
> > > > I think the nested property approach is correct. Sorry for causing
> the
> > > > confusion.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
> > > >
> > > > > Ilya,
> > > > >
> > > > > Sorry, I've just got your first message wrong. I though, you were
> > > > > proposing to remove ClientConnectorConfiguration altogether, my
> bad.
> > > > >
> > > > > Now, about separating ClientConnectorConfiguration and - I do not
> > > > > propose to make it a copy with the same options. What I was
> proposing
> > > > > is to keep common settings in ClientConnectorConfiguration and
> place
> > > > > thin client specific things in a separate class which is going to
> be
> > > > nested
> > > > > as a property of ClientConnectorConfiguration.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I don't see why it should break backward compatibility and
> > protocol.
> > > > Can
> > > > > > you please elaborate? I imagine that Thin client with TX muxing
> > > support
> > > > > > will just send different requests to which server will respond
> > > > > differently.
> > > > > > Why would anything break?
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > > > > >
> > > > > > > Ilya,
> > > > > > >
> > > > > > > This will break backward compatibility and probably protocol,
> and
> > > > this
> > > > > is
> > > > > > > not something we should discuss in the context of this specific
> > > task.
> > > > > > More
> > > > > > > like this is a topic for 3.0 wishlist.
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Igor
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > > > > ilya.kasnach...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Also, let's not add IGNITE_ settings for options that can
> > > > reasonably
> > > > > be
> > > > > > > > configured from IgniteConfiguration. Let's keep it for very
> > edge
> > > > > cases.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > >
> > > > > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > > > > ilya.kasnach...@gmail.com
> > > > > > > >:
> > > > > > > >
> > > > > > > > > Hello!
> > > > > > > > >
> > > > > > > > > Do we still need to separate client connector configuration
> > > from
> > > > > thin
> > > > > > > > > connector configuration from ODBC connector configuration?
> > > > > > > > >
> > > > > > > > > I think this is a bad practice: For example, people often
> > turn
> > > on
> > > > > SSL
> > > > > > > or
> > > > > > > > > auth on just a subset of connectors, think they are secure,
> > > when
> > > > in
> > > > > > > fact
> > > > > > > > > they still have unsecured connector around (e.g. ODBC) and
> > > their
> > > > > data
> > > > > > > is

Re: Thin client: transactions support

[Alex Plehanov]

Pavel, we already have OdbcEnabled, JdbcEnabled and ThinClientEnabled
properties inside ClientConnectorConfiguration. ThinClientEnabled=false
does not assume that JDBC thin client is disabled, it's clear and not
confusing. I'm not agreed that the same situation with
ThinClientConfiguration will be confusing, the same logic works here as for
ThinClientEnabled flag. At least we can add JavaDoc that this configuration
is not related to JDBC and ODBC, but I think it's redundant.

ср, 28 авг. 2019 г. в 12:41, Pavel Tupitsyn :

> ThinClientConfiguration name is very confusing in existing situation.
> E.g. does it apply to JDBC Thin Client? No, it does not, but it is easy to
> assume it does.
>
> On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov 
> wrote:
>
> > Ilya, Igor,
> >
> > Nested property is what exactly I've done in the last fix.
> > ClientConnectorConfiguration now includes ThinClientConfiguration which
> > contain only one property MaxActiveTxPerConnection for now.
> >
> > Pavel,
> >
> > Why do you think that nested ThinClientConfiguration is more confusing
> than
> > property in common configuration which related only to part of
> configurable
> > elements? In case of nested configuration, user will know that property
> is
> > related only to thin client even without reference to JavaDoc.
> > Now it's only one such property, but if continue to introduce specific
> > properties to the common configuration in the future, after a while there
> > will be a mess.
> >
> >
> > вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > I think the nested property approach is correct. Sorry for causing the
> > > confusion.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
> > >
> > > > Ilya,
> > > >
> > > > Sorry, I've just got your first message wrong. I though, you were
> > > > proposing to remove ClientConnectorConfiguration altogether, my bad.
> > > >
> > > > Now, about separating ClientConnectorConfiguration and - I do not
> > > > propose to make it a copy with the same options. What I was proposing
> > > > is to keep common settings in ClientConnectorConfiguration and place
> > > > thin client specific things in a separate class which is going to be
> > > nested
> > > > as a property of ClientConnectorConfiguration.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > I don't see why it should break backward compatibility and
> protocol.
> > > Can
> > > > > you please elaborate? I imagine that Thin client with TX muxing
> > support
> > > > > will just send different requests to which server will respond
> > > > differently.
> > > > > Why would anything break?
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > > > >
> > > > > > Ilya,
> > > > > >
> > > > > > This will break backward compatibility and probably protocol, and
> > > this
> > > > is
> > > > > > not something we should discuss in the context of this specific
> > task.
> > > > > More
> > > > > > like this is a topic for 3.0 wishlist.
> > > > > >
> > > > > > Best Regards,
> > > > > > Igor
> > > > > >
> > > > > >
> > > > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > > > ilya.kasnach...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Also, let's not add IGNITE_ settings for options that can
> > > reasonably
> > > > be
> > > > > > > configured from IgniteConfiguration. Let's keep it for very
> edge
> > > > cases.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com
> > > > > > >:
> > > > > > >
> > > > > > > > Hello!
> > > > > > > >
> > > > > > > > Do we still need to separate client connector configuration
> > from
> > > > thin
> > > > > > > > connector configuration from ODBC connector configuration?
> > > > > > > >
> > > > > > > > I think this is a bad practice: For example, people often
> turn
> > on
> > > > SSL
> > > > > > or
> > > > > > > > auth on just a subset of connectors, think they are secure,
> > when
> > > in
> > > > > > fact
> > > > > > > > they still have unsecured connector around (e.g. ODBC) and
> > their
> > > > data
> > > > > > is
> > > > > > > > not protected at all.
> > > > > > > >
> > > > > > > > It may solve some specific issue that you are facing, but for
> > > > > newcomers
> > > > > > > to
> > > > > > > > project it is a drawback. I think we should seek to not add
> > > > connector
> > > > > > > > configurations anymore.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > --
> > > > > > > > Ilya Kasnacheev
> > > > > > > >
> > > > > > > >
> > > > > > > > пт, 23 авг. 2019 г. в 20:49, 

Re: Thin client: transactions support

[Pavel Tupitsyn]

ThinClientConfiguration name is very confusing in existing situation.
E.g. does it apply to JDBC Thin Client? No, it does not, but it is easy to
assume it does.

On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov 
wrote:

> Ilya, Igor,
>
> Nested property is what exactly I've done in the last fix.
> ClientConnectorConfiguration now includes ThinClientConfiguration which
> contain only one property MaxActiveTxPerConnection for now.
>
> Pavel,
>
> Why do you think that nested ThinClientConfiguration is more confusing than
> property in common configuration which related only to part of configurable
> elements? In case of nested configuration, user will know that property is
> related only to thin client even without reference to JavaDoc.
> Now it's only one such property, but if continue to introduce specific
> properties to the common configuration in the future, after a while there
> will be a mess.
>
>
> вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev :
>
> > Hello!
> >
> > I think the nested property approach is correct. Sorry for causing the
> > confusion.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
> >
> > > Ilya,
> > >
> > > Sorry, I've just got your first message wrong. I though, you were
> > > proposing to remove ClientConnectorConfiguration altogether, my bad.
> > >
> > > Now, about separating ClientConnectorConfiguration and - I do not
> > > propose to make it a copy with the same options. What I was proposing
> > > is to keep common settings in ClientConnectorConfiguration and place
> > > thin client specific things in a separate class which is going to be
> > nested
> > > as a property of ClientConnectorConfiguration.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > I don't see why it should break backward compatibility and protocol.
> > Can
> > > > you please elaborate? I imagine that Thin client with TX muxing
> support
> > > > will just send different requests to which server will respond
> > > differently.
> > > > Why would anything break?
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > > >
> > > > > Ilya,
> > > > >
> > > > > This will break backward compatibility and probably protocol, and
> > this
> > > is
> > > > > not something we should discuss in the context of this specific
> task.
> > > > More
> > > > > like this is a topic for 3.0 wishlist.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Also, let's not add IGNITE_ settings for options that can
> > reasonably
> > > be
> > > > > > configured from IgniteConfiguration. Let's keep it for very edge
> > > cases.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com
> > > > > >:
> > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > Do we still need to separate client connector configuration
> from
> > > thin
> > > > > > > connector configuration from ODBC connector configuration?
> > > > > > >
> > > > > > > I think this is a bad practice: For example, people often turn
> on
> > > SSL
> > > > > or
> > > > > > > auth on just a subset of connectors, think they are secure,
> when
> > in
> > > > > fact
> > > > > > > they still have unsecured connector around (e.g. ODBC) and
> their
> > > data
> > > > > is
> > > > > > > not protected at all.
> > > > > > >
> > > > > > > It may solve some specific issue that you are facing, but for
> > > > newcomers
> > > > > > to
> > > > > > > project it is a drawback. I think we should seek to not add
> > > connector
> > > > > > > configurations anymore.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <
> > > plehanov.a...@gmail.com
> > > > >:
> > > > > > >
> > > > > > >> Pavel,
> > > > > > >>
> > > > > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > > > > clients,
> > > > > > >> the
> > > > > > >> new property only related to thin clients. If we put the new
> > > > property
> > > > > > >> directly into ClientConnectorConfiguration, someone might
> think
> > > that
> > > > > it
> > > > > > >> also affects JDBC and ODBC.
> > > > > > >>
> > > > > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >:
> > > > > > >>
> > > > > > >> > Igor, Alex,
> > > > > > >> >
> > > > > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > > > > >> > ClientConnectorConfiguration.
> > > > > > >> > Very confusing IMO, because 

Re: Thin client: transactions support

[Alex Plehanov]

Ilya, Igor,

Nested property is what exactly I've done in the last fix.
ClientConnectorConfiguration now includes ThinClientConfiguration which
contain only one property MaxActiveTxPerConnection for now.

Pavel,

Why do you think that nested ThinClientConfiguration is more confusing than
property in common configuration which related only to part of configurable
elements? In case of nested configuration, user will know that property is
related only to thin client even without reference to JavaDoc.
Now it's only one such property, but if continue to introduce specific
properties to the common configuration in the future, after a while there
will be a mess.


вт, 27 авг. 2019 г. в 15:18, Ilya Kasnacheev :

> Hello!
>
> I think the nested property approach is correct. Sorry for causing the
> confusion.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 27 авг. 2019 г. в 15:06, Igor Sapego :
>
> > Ilya,
> >
> > Sorry, I've just got your first message wrong. I though, you were
> > proposing to remove ClientConnectorConfiguration altogether, my bad.
> >
> > Now, about separating ClientConnectorConfiguration and - I do not
> > propose to make it a copy with the same options. What I was proposing
> > is to keep common settings in ClientConnectorConfiguration and place
> > thin client specific things in a separate class which is going to be
> nested
> > as a property of ClientConnectorConfiguration.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > I don't see why it should break backward compatibility and protocol.
> Can
> > > you please elaborate? I imagine that Thin client with TX muxing support
> > > will just send different requests to which server will respond
> > differently.
> > > Why would anything break?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> > >
> > > > Ilya,
> > > >
> > > > This will break backward compatibility and probably protocol, and
> this
> > is
> > > > not something we should discuss in the context of this specific task.
> > > More
> > > > like this is a topic for 3.0 wishlist.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello!
> > > > >
> > > > > Also, let's not add IGNITE_ settings for options that can
> reasonably
> > be
> > > > > configured from IgniteConfiguration. Let's keep it for very edge
> > cases.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > >:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Do we still need to separate client connector configuration from
> > thin
> > > > > > connector configuration from ODBC connector configuration?
> > > > > >
> > > > > > I think this is a bad practice: For example, people often turn on
> > SSL
> > > > or
> > > > > > auth on just a subset of connectors, think they are secure, when
> in
> > > > fact
> > > > > > they still have unsecured connector around (e.g. ODBC) and their
> > data
> > > > is
> > > > > > not protected at all.
> > > > > >
> > > > > > It may solve some specific issue that you are facing, but for
> > > newcomers
> > > > > to
> > > > > > project it is a drawback. I think we should seek to not add
> > connector
> > > > > > configurations anymore.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <
> > plehanov.a...@gmail.com
> > > >:
> > > > > >
> > > > > >> Pavel,
> > > > > >>
> > > > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > > > clients,
> > > > > >> the
> > > > > >> new property only related to thin clients. If we put the new
> > > property
> > > > > >> directly into ClientConnectorConfiguration, someone might think
> > that
> > > > it
> > > > > >> also affects JDBC and ODBC.
> > > > > >>
> > > > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > > > >>
> > > > > >> > Igor, Alex,
> > > > > >> >
> > > > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > > > >> > ClientConnectorConfiguration.
> > > > > >> > Very confusing IMO, because ClientConnectorConfiguration is
> > > already
> > > > > >> related
> > > > > >> > to thin clients only.
> > > > > >> >
> > > > > >> > Why not put the new property directly into
> > > > > ClientConnectorConfiguration?
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

I think the nested property approach is correct. Sorry for causing the
confusion.

Regards,
-- 
Ilya Kasnacheev


вт, 27 авг. 2019 г. в 15:06, Igor Sapego :

> Ilya,
>
> Sorry, I've just got your first message wrong. I though, you were
> proposing to remove ClientConnectorConfiguration altogether, my bad.
>
> Now, about separating ClientConnectorConfiguration and - I do not
> propose to make it a copy with the same options. What I was proposing
> is to keep common settings in ClientConnectorConfiguration and place
> thin client specific things in a separate class which is going to be nested
> as a property of ClientConnectorConfiguration.
>
> Best Regards,
> Igor
>
>
> On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> wrote:
>
> > Hello!
> >
> > I don't see why it should break backward compatibility and protocol. Can
> > you please elaborate? I imagine that Thin client with TX muxing support
> > will just send different requests to which server will respond
> differently.
> > Why would anything break?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
> >
> > > Ilya,
> > >
> > > This will break backward compatibility and probably protocol, and this
> is
> > > not something we should discuss in the context of this specific task.
> > More
> > > like this is a topic for 3.0 wishlist.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com>
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > Also, let's not add IGNITE_ settings for options that can reasonably
> be
> > > > configured from IgniteConfiguration. Let's keep it for very edge
> cases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >:
> > > >
> > > > > Hello!
> > > > >
> > > > > Do we still need to separate client connector configuration from
> thin
> > > > > connector configuration from ODBC connector configuration?
> > > > >
> > > > > I think this is a bad practice: For example, people often turn on
> SSL
> > > or
> > > > > auth on just a subset of connectors, think they are secure, when in
> > > fact
> > > > > they still have unsecured connector around (e.g. ODBC) and their
> data
> > > is
> > > > > not protected at all.
> > > > >
> > > > > It may solve some specific issue that you are facing, but for
> > newcomers
> > > > to
> > > > > project it is a drawback. I think we should seek to not add
> connector
> > > > > configurations anymore.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > >
> > > > >> Pavel,
> > > > >>
> > > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > > clients,
> > > > >> the
> > > > >> new property only related to thin clients. If we put the new
> > property
> > > > >> directly into ClientConnectorConfiguration, someone might think
> that
> > > it
> > > > >> also affects JDBC and ODBC.
> > > > >>
> > > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn  >:
> > > > >>
> > > > >> > Igor, Alex,
> > > > >> >
> > > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > > >> > ClientConnectorConfiguration.
> > > > >> > Very confusing IMO, because ClientConnectorConfiguration is
> > already
> > > > >> related
> > > > >> > to thin clients only.
> > > > >> >
> > > > >> > Why not put the new property directly into
> > > > ClientConnectorConfiguration?
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: Thin client: transactions support

[Igor Sapego]

Ilya,

Sorry, I've just got your first message wrong. I though, you were
proposing to remove ClientConnectorConfiguration altogether, my bad.

Now, about separating ClientConnectorConfiguration and - I do not
propose to make it a copy with the same options. What I was proposing
is to keep common settings in ClientConnectorConfiguration and place
thin client specific things in a separate class which is going to be nested
as a property of ClientConnectorConfiguration.

Best Regards,
Igor


On Tue, Aug 27, 2019 at 12:12 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> I don't see why it should break backward compatibility and protocol. Can
> you please elaborate? I imagine that Thin client with TX muxing support
> will just send different requests to which server will respond differently.
> Why would anything break?
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 26 авг. 2019 г. в 14:16, Igor Sapego :
>
> > Ilya,
> >
> > This will break backward compatibility and probably protocol, and this is
> > not something we should discuss in the context of this specific task.
> More
> > like this is a topic for 3.0 wishlist.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > Also, let's not add IGNITE_ settings for options that can reasonably be
> > > configured from IgniteConfiguration. Let's keep it for very edge cases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >:
> > >
> > > > Hello!
> > > >
> > > > Do we still need to separate client connector configuration from thin
> > > > connector configuration from ODBC connector configuration?
> > > >
> > > > I think this is a bad practice: For example, people often turn on SSL
> > or
> > > > auth on just a subset of connectors, think they are secure, when in
> > fact
> > > > they still have unsecured connector around (e.g. ODBC) and their data
> > is
> > > > not protected at all.
> > > >
> > > > It may solve some specific issue that you are facing, but for
> newcomers
> > > to
> > > > project it is a drawback. I think we should seek to not add connector
> > > > configurations anymore.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov  >:
> > > >
> > > >> Pavel,
> > > >>
> > > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> > clients,
> > > >> the
> > > >> new property only related to thin clients. If we put the new
> property
> > > >> directly into ClientConnectorConfiguration, someone might think that
> > it
> > > >> also affects JDBC and ODBC.
> > > >>
> > > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
> > > >>
> > > >> > Igor, Alex,
> > > >> >
> > > >> > Not sure I agree with this: ThinClientConfiguration inside
> > > >> > ClientConnectorConfiguration.
> > > >> > Very confusing IMO, because ClientConnectorConfiguration is
> already
> > > >> related
> > > >> > to thin clients only.
> > > >> >
> > > >> > Why not put the new property directly into
> > > ClientConnectorConfiguration?
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

I don't see why it should break backward compatibility and protocol. Can
you please elaborate? I imagine that Thin client with TX muxing support
will just send different requests to which server will respond differently.
Why would anything break?

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 14:16, Igor Sapego :

> Ilya,
>
> This will break backward compatibility and probably protocol, and this is
> not something we should discuss in the context of this specific task. More
> like this is a topic for 3.0 wishlist.
>
> Best Regards,
> Igor
>
>
> On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> wrote:
>
> > Hello!
> >
> > Also, let's not add IGNITE_ settings for options that can reasonably be
> > configured from IgniteConfiguration. Let's keep it for very edge cases.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev  >:
> >
> > > Hello!
> > >
> > > Do we still need to separate client connector configuration from thin
> > > connector configuration from ODBC connector configuration?
> > >
> > > I think this is a bad practice: For example, people often turn on SSL
> or
> > > auth on just a subset of connectors, think they are secure, when in
> fact
> > > they still have unsecured connector around (e.g. ODBC) and their data
> is
> > > not protected at all.
> > >
> > > It may solve some specific issue that you are facing, but for newcomers
> > to
> > > project it is a drawback. I think we should seek to not add connector
> > > configurations anymore.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov :
> > >
> > >> Pavel,
> > >>
> > >> ClientConnectorConfiguration is related to JDBC, ODBC and thin
> clients,
> > >> the
> > >> new property only related to thin clients. If we put the new property
> > >> directly into ClientConnectorConfiguration, someone might think that
> it
> > >> also affects JDBC and ODBC.
> > >>
> > >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
> > >>
> > >> > Igor, Alex,
> > >> >
> > >> > Not sure I agree with this: ThinClientConfiguration inside
> > >> > ClientConnectorConfiguration.
> > >> > Very confusing IMO, because ClientConnectorConfiguration is already
> > >> related
> > >> > to thin clients only.
> > >> >
> > >> > Why not put the new property directly into
> > ClientConnectorConfiguration?
> > >> >
> > >>
> > >
> >
>

Re: Thin client: transactions support

[Igor Sapego]

Ilya,

This will break backward compatibility and probably protocol, and this is
not something we should discuss in the context of this specific task. More
like this is a topic for 3.0 wishlist.

Best Regards,
Igor


On Mon, Aug 26, 2019 at 12:28 PM Ilya Kasnacheev 
wrote:

> Hello!
>
> Also, let's not add IGNITE_ settings for options that can reasonably be
> configured from IgniteConfiguration. Let's keep it for very edge cases.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev :
>
> > Hello!
> >
> > Do we still need to separate client connector configuration from thin
> > connector configuration from ODBC connector configuration?
> >
> > I think this is a bad practice: For example, people often turn on SSL or
> > auth on just a subset of connectors, think they are secure, when in fact
> > they still have unsecured connector around (e.g. ODBC) and their data is
> > not protected at all.
> >
> > It may solve some specific issue that you are facing, but for newcomers
> to
> > project it is a drawback. I think we should seek to not add connector
> > configurations anymore.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 23 авг. 2019 г. в 20:49, Alex Plehanov :
> >
> >> Pavel,
> >>
> >> ClientConnectorConfiguration is related to JDBC, ODBC and thin clients,
> >> the
> >> new property only related to thin clients. If we put the new property
> >> directly into ClientConnectorConfiguration, someone might think that it
> >> also affects JDBC and ODBC.
> >>
> >> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
> >>
> >> > Igor, Alex,
> >> >
> >> > Not sure I agree with this: ThinClientConfiguration inside
> >> > ClientConnectorConfiguration.
> >> > Very confusing IMO, because ClientConnectorConfiguration is already
> >> related
> >> > to thin clients only.
> >> >
> >> > Why not put the new property directly into
> ClientConnectorConfiguration?
> >> >
> >>
> >
>

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

Also, let's not add IGNITE_ settings for options that can reasonably be
configured from IgniteConfiguration. Let's keep it for very edge cases.

Regards,
-- 
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev :

> Hello!
>
> Do we still need to separate client connector configuration from thin
> connector configuration from ODBC connector configuration?
>
> I think this is a bad practice: For example, people often turn on SSL or
> auth on just a subset of connectors, think they are secure, when in fact
> they still have unsecured connector around (e.g. ODBC) and their data is
> not protected at all.
>
> It may solve some specific issue that you are facing, but for newcomers to
> project it is a drawback. I think we should seek to not add connector
> configurations anymore.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 23 авг. 2019 г. в 20:49, Alex Plehanov :
>
>> Pavel,
>>
>> ClientConnectorConfiguration is related to JDBC, ODBC and thin clients,
>> the
>> new property only related to thin clients. If we put the new property
>> directly into ClientConnectorConfiguration, someone might think that it
>> also affects JDBC and ODBC.
>>
>> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
>>
>> > Igor, Alex,
>> >
>> > Not sure I agree with this: ThinClientConfiguration inside
>> > ClientConnectorConfiguration.
>> > Very confusing IMO, because ClientConnectorConfiguration is already
>> related
>> > to thin clients only.
>> >
>> > Why not put the new property directly into ClientConnectorConfiguration?
>> >
>>
>

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

Do we still need to separate client connector configuration from thin
connector configuration from ODBC connector configuration?

I think this is a bad practice: For example, people often turn on SSL or
auth on just a subset of connectors, think they are secure, when in fact
they still have unsecured connector around (e.g. ODBC) and their data is
not protected at all.

It may solve some specific issue that you are facing, but for newcomers to
project it is a drawback. I think we should seek to not add connector
configurations anymore.

Regards,
-- 
Ilya Kasnacheev


пт, 23 авг. 2019 г. в 20:49, Alex Plehanov :

> Pavel,
>
> ClientConnectorConfiguration is related to JDBC, ODBC and thin clients, the
> new property only related to thin clients. If we put the new property
> directly into ClientConnectorConfiguration, someone might think that it
> also affects JDBC and ODBC.
>
> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
>
> > Igor, Alex,
> >
> > Not sure I agree with this: ThinClientConfiguration inside
> > ClientConnectorConfiguration.
> > Very confusing IMO, because ClientConnectorConfiguration is already
> related
> > to thin clients only.
> >
> > Why not put the new property directly into ClientConnectorConfiguration?
> >
>

Re: Thin client: transactions support

[Pavel Tupitsyn]

I think it is less confusing than  ThinClientConfiguration.

On Fri, Aug 23, 2019 at 8:49 PM Alex Plehanov 
wrote:

> Pavel,
>
> ClientConnectorConfiguration is related to JDBC, ODBC and thin clients, the
> new property only related to thin clients. If we put the new property
> directly into ClientConnectorConfiguration, someone might think that it
> also affects JDBC and ODBC.
>
> пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :
>
> > Igor, Alex,
> >
> > Not sure I agree with this: ThinClientConfiguration inside
> > ClientConnectorConfiguration.
> > Very confusing IMO, because ClientConnectorConfiguration is already
> related
> > to thin clients only.
> >
> > Why not put the new property directly into ClientConnectorConfiguration?
> >
>

Re: Thin client: transactions support

[Alex Plehanov]

Pavel,

ClientConnectorConfiguration is related to JDBC, ODBC and thin clients, the
new property only related to thin clients. If we put the new property
directly into ClientConnectorConfiguration, someone might think that it
also affects JDBC and ODBC.

пт, 23 авг. 2019 г. в 19:59, Pavel Tupitsyn :

> Igor, Alex,
>
> Not sure I agree with this: ThinClientConfiguration inside
> ClientConnectorConfiguration.
> Very confusing IMO, because ClientConnectorConfiguration is already related
> to thin clients only.
>
> Why not put the new property directly into ClientConnectorConfiguration?
>

Re: Thin client: transactions support

[Alex Plehanov]

Igor,

Make sense. I've fixed the implementation according to your proposal.

ср, 21 авг. 2019 г. в 17:59, Igor Sapego :

> Probably, we need separate configuration for
> Thin Clients as a part of ClientConnectorConfiguration?
>
> Best Regards,
> Igor
>
>
> On Thu, Aug 15, 2019 at 12:36 PM Alex Plehanov 
> wrote:
>
> > Hi Pavel,
> >
> > Thank you for the review!
> >
> > Igniters,
> >
> > Also, I want to bring here a discussion about configuring limit for
> active
> > transactions per thin client connection.
> >
> > I see two ways to configure such limit:
> > 1. A new system property
> > 2. A new ClientConnectorConfiguration class property.
> >
> > In the current implementation, I've introduced a new system
> > property IGNITE_THIN_MAX_ACTIVE_TX_PER_CONNECTION. Pavel proposes to
> > configure limit via ClientConnectorConfiguration.
> >
> > Such limit is only reliable to thin clients, but
> > ClientConnectorConfiguration is also used for JDBC and ODBC connections
> as
> > well. A new property in ClientConnectorConfiguration will be useless for
> > JDBC and ODBC (since they use one transaction per connection) and may be
> > confusing.
> >
> > Which way is better, WDYT?
> >
> >
> >
> > чт, 15 авг. 2019 г. в 11:46, Pavel Tupitsyn :
> >
> > > Hi Alex,
> > >
> > > I've checked the patch, protocol changes look good to me. See reply in
> > > Jira.
> > > But we certainly need more eyes on this.
> > >
> > > On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov <
> plehanov.a...@gmail.com>
> > > wrote:
> > >
> > > > Hi Ivan,
> > > >
> > > > Java thin client doesn't support affinity awareness yet (ticket [1]
> is
> > in
> > > > progress now), but changes to correctly work with protocol version
> > 1.4.0
> > > > was made, so java thin client will work properly with 1.4.0 and 1.5.0
> > > > protocol versions.
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/IGNITE-11898
> > > >
> > > > чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > Could you please elaborate about thin client protocol versioning.
> As
> > I
> > > > > see 1.5.0 is supposed to be a version supporting transactions. And
> we
> > > > > already have a version 1.4.0 with affinity awareness support. I
> > > > > forgot, does Java thin client support affinity awareness? Will it
> > work
> > > > > properly if it does not?
> > > > >
> > > > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > > >
> > > > > > Hi Igniters,
> > > > > >
> > > > > > Finally, all dependent tickets are resolved and I've completed
> the
> > > > > > implementation of thin client transactions support. The patch [1]
> > > > > includes
> > > > > > server-side implementation and java thin client-side
> > implementation.
> > > > > > Changes to thin client protocol and top-level view of
> > implementation
> > > > also
> > > > > > described in IEP [2].
> > > > > > Can anyone review the patch?
> > > > > >
> > > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > > > > > [2]:
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > > > >
> > > > > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > > >
> > > > > > > Ivan,
> > > > > > >
> > > > > > > Yes, .NET client has such capability. Pavel Tupitsyn already
> > > mentions
> > > > > it
> > > > > > > in this thread. As far as I understand, in .NET client
> > > implementation
> > > > > to
> > > > > > > dispatch responses dedicated thread is used.
> > > > > > > In a draft implementation of IGNITE-11685 I've used another
> > > approach:
> > > > > each
> > > > > > > request thread can read a response (if lock is acquired by this
> > &g

Re: Thin client: transactions support

[Igor Sapego]

Probably, we need separate configuration for
Thin Clients as a part of ClientConnectorConfiguration?

Best Regards,
Igor


On Thu, Aug 15, 2019 at 12:36 PM Alex Plehanov 
wrote:

> Hi Pavel,
>
> Thank you for the review!
>
> Igniters,
>
> Also, I want to bring here a discussion about configuring limit for active
> transactions per thin client connection.
>
> I see two ways to configure such limit:
> 1. A new system property
> 2. A new ClientConnectorConfiguration class property.
>
> In the current implementation, I've introduced a new system
> property IGNITE_THIN_MAX_ACTIVE_TX_PER_CONNECTION. Pavel proposes to
> configure limit via ClientConnectorConfiguration.
>
> Such limit is only reliable to thin clients, but
> ClientConnectorConfiguration is also used for JDBC and ODBC connections as
> well. A new property in ClientConnectorConfiguration will be useless for
> JDBC and ODBC (since they use one transaction per connection) and may be
> confusing.
>
> Which way is better, WDYT?
>
>
>
> чт, 15 авг. 2019 г. в 11:46, Pavel Tupitsyn :
>
> > Hi Alex,
> >
> > I've checked the patch, protocol changes look good to me. See reply in
> > Jira.
> > But we certainly need more eyes on this.
> >
> > On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov 
> > wrote:
> >
> > > Hi Ivan,
> > >
> > > Java thin client doesn't support affinity awareness yet (ticket [1] is
> in
> > > progress now), but changes to correctly work with protocol version
> 1.4.0
> > > was made, so java thin client will work properly with 1.4.0 and 1.5.0
> > > protocol versions.
> > >
> > > [1]: https://issues.apache.org/jira/browse/IGNITE-11898
> > >
> > > чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :
> > >
> > > > Hi Alex,
> > > >
> > > > Could you please elaborate about thin client protocol versioning. As
> I
> > > > see 1.5.0 is supposed to be a version supporting transactions. And we
> > > > already have a version 1.4.0 with affinity awareness support. I
> > > > forgot, does Java thin client support affinity awareness? Will it
> work
> > > > properly if it does not?
> > > >
> > > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov  >:
> > > > >
> > > > > Hi Igniters,
> > > > >
> > > > > Finally, all dependent tickets are resolved and I've completed the
> > > > > implementation of thin client transactions support. The patch [1]
> > > > includes
> > > > > server-side implementation and java thin client-side
> implementation.
> > > > > Changes to thin client protocol and top-level view of
> implementation
> > > also
> > > > > described in IEP [2].
> > > > > Can anyone review the patch?
> > > > >
> > > > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > > > > [2]:
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > > >
> > > > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov  >:
> > > > >
> > > > > > Ivan,
> > > > > >
> > > > > > Yes, .NET client has such capability. Pavel Tupitsyn already
> > mentions
> > > > it
> > > > > > in this thread. As far as I understand, in .NET client
> > implementation
> > > > to
> > > > > > dispatch responses dedicated thread is used.
> > > > > > In a draft implementation of IGNITE-11685 I've used another
> > approach:
> > > > each
> > > > > > request thread can read a response (if lock is acquired by this
> > > thread
> > > > > > successfully) and complete a future of its own request or another
> > > > threads
> > > > > > request.
> > > > > >
> > > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > > > > >
> > > > > >> Alex,
> > > > > >>
> > > > > >> I am quite curious about async implementations from other
> clients.
> > > Is
> > > > > >> there any design document describing such implementations? Does
> > .NET
> > > > > >> client have such capability?
> > > > > >>
> > > > > >> Actually, I forgot to finish my previous message. One of my
> >

Re: Thin client: transactions support

[Alex Plehanov]

Hi Pavel,

Thank you for the review!

Igniters,

Also, I want to bring here a discussion about configuring limit for active
transactions per thin client connection.

I see two ways to configure such limit:
1. A new system property
2. A new ClientConnectorConfiguration class property.

In the current implementation, I've introduced a new system
property IGNITE_THIN_MAX_ACTIVE_TX_PER_CONNECTION. Pavel proposes to
configure limit via ClientConnectorConfiguration.

Such limit is only reliable to thin clients, but
ClientConnectorConfiguration is also used for JDBC and ODBC connections as
well. A new property in ClientConnectorConfiguration will be useless for
JDBC and ODBC (since they use one transaction per connection) and may be
confusing.

Which way is better, WDYT?



чт, 15 авг. 2019 г. в 11:46, Pavel Tupitsyn :

> Hi Alex,
>
> I've checked the patch, protocol changes look good to me. See reply in
> Jira.
> But we certainly need more eyes on this.
>
> On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov 
> wrote:
>
> > Hi Ivan,
> >
> > Java thin client doesn't support affinity awareness yet (ticket [1] is in
> > progress now), but changes to correctly work with protocol version 1.4.0
> > was made, so java thin client will work properly with 1.4.0 and 1.5.0
> > protocol versions.
> >
> > [1]: https://issues.apache.org/jira/browse/IGNITE-11898
> >
> > чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :
> >
> > > Hi Alex,
> > >
> > > Could you please elaborate about thin client protocol versioning. As I
> > > see 1.5.0 is supposed to be a version supporting transactions. And we
> > > already have a version 1.4.0 with affinity awareness support. I
> > > forgot, does Java thin client support affinity awareness? Will it work
> > > properly if it does not?
> > >
> > > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
> > > >
> > > > Hi Igniters,
> > > >
> > > > Finally, all dependent tickets are resolved and I've completed the
> > > > implementation of thin client transactions support. The patch [1]
> > > includes
> > > > server-side implementation and java thin client-side implementation.
> > > > Changes to thin client protocol and top-level view of implementation
> > also
> > > > described in IEP [2].
> > > > Can anyone review the patch?
> > > >
> > > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > > > [2]:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > >
> > > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
> > > >
> > > > > Ivan,
> > > > >
> > > > > Yes, .NET client has such capability. Pavel Tupitsyn already
> mentions
> > > it
> > > > > in this thread. As far as I understand, in .NET client
> implementation
> > > to
> > > > > dispatch responses dedicated thread is used.
> > > > > In a draft implementation of IGNITE-11685 I've used another
> approach:
> > > each
> > > > > request thread can read a response (if lock is acquired by this
> > thread
> > > > > successfully) and complete a future of its own request or another
> > > threads
> > > > > request.
> > > > >
> > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > > > >
> > > > >> Alex,
> > > > >>
> > > > >> I am quite curious about async implementations from other clients.
> > Is
> > > > >> there any design document describing such implementations? Does
> .NET
> > > > >> client have such capability?
> > > > >>
> > > > >> Actually, I forgot to finish my previous message. One of my
> concerns
> > > > >> is that a concurrent response dispatch does not sound as a trivial
> > > > >> thing. So, I would like to understand if we already have a good
> > > > >> approach for that. If not then I suppose it worth a discussion.
> > > > >>
> > > > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov <
> plehanov.a...@gmail.com
> > >:
> > > > >> >
> > > > >> > Hi Ivan.
> > > > >> >
> > > > >> > Thin client transactions support is not only for java thin
> client.
> > > There
> > > > >> > are other clients, some of them already work in 

Re: Thin client: transactions support

[Pavel Tupitsyn]

Hi Alex,

I've checked the patch, protocol changes look good to me. See reply in Jira.
But we certainly need more eyes on this.

On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov 
wrote:

> Hi Ivan,
>
> Java thin client doesn't support affinity awareness yet (ticket [1] is in
> progress now), but changes to correctly work with protocol version 1.4.0
> was made, so java thin client will work properly with 1.4.0 and 1.5.0
> protocol versions.
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-11898
>
> чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :
>
> > Hi Alex,
> >
> > Could you please elaborate about thin client protocol versioning. As I
> > see 1.5.0 is supposed to be a version supporting transactions. And we
> > already have a version 1.4.0 with affinity awareness support. I
> > forgot, does Java thin client support affinity awareness? Will it work
> > properly if it does not?
> >
> > ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
> > >
> > > Hi Igniters,
> > >
> > > Finally, all dependent tickets are resolved and I've completed the
> > > implementation of thin client transactions support. The patch [1]
> > includes
> > > server-side implementation and java thin client-side implementation.
> > > Changes to thin client protocol and top-level view of implementation
> also
> > > described in IEP [2].
> > > Can anyone review the patch?
> > >
> > > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > > [2]:
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >
> > > пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
> > >
> > > > Ivan,
> > > >
> > > > Yes, .NET client has such capability. Pavel Tupitsyn already mentions
> > it
> > > > in this thread. As far as I understand, in .NET client implementation
> > to
> > > > dispatch responses dedicated thread is used.
> > > > In a draft implementation of IGNITE-11685 I've used another approach:
> > each
> > > > request thread can read a response (if lock is acquired by this
> thread
> > > > successfully) and complete a future of its own request or another
> > threads
> > > > request.
> > > >
> > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > > >
> > > >> Alex,
> > > >>
> > > >> I am quite curious about async implementations from other clients.
> Is
> > > >> there any design document describing such implementations? Does .NET
> > > >> client have such capability?
> > > >>
> > > >> Actually, I forgot to finish my previous message. One of my concerns
> > > >> is that a concurrent response dispatch does not sound as a trivial
> > > >> thing. So, I would like to understand if we already have a good
> > > >> approach for that. If not then I suppose it worth a discussion.
> > > >>
> > > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov  >:
> > > >> >
> > > >> > Hi Ivan.
> > > >> >
> > > >> > Thin client transactions support is not only for java thin client.
> > There
> > > >> > are other clients, some of them already work in async mode.
> > > >> > Ticket IGNITE-11685 already has draft implementation too, but now
> > it's
> > > >> > based on some changes to java thin client which were made by
> > > >> "transaction
> > > >> > support" implementation. I think this ticket will be ready in a
> > couple
> > > >> of
> > > >> > days after "transaction support" will be merged. And both patches
> > will
> > > >> be
> > > >> > included in the same release.
> > > >> >
> > > >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> > > >> >
> > > >> > > Hi Alex,
> > > >> > >
> > > >> > > Regarding a problem with possible deadlock when two concurrent
> > > >> > > transactions from the same client are trying to lock the same
> key
> > and
> > > >> > > an issue [1]. It seems to me that without fixing the issue [1] a
> > > >> > > client transactions feature is not practical. Everyone who uses
> a
> > > >> > > client from multiple threads can face a

Re: Thin client: transactions support

[Alex Plehanov]

Hi Ivan,

Java thin client doesn't support affinity awareness yet (ticket [1] is in
progress now), but changes to correctly work with protocol version 1.4.0
was made, so java thin client will work properly with 1.4.0 and 1.5.0
protocol versions.

[1]: https://issues.apache.org/jira/browse/IGNITE-11898

чт, 15 авг. 2019 г. в 10:23, Павлухин Иван :

> Hi Alex,
>
> Could you please elaborate about thin client protocol versioning. As I
> see 1.5.0 is supposed to be a version supporting transactions. And we
> already have a version 1.4.0 with affinity awareness support. I
> forgot, does Java thin client support affinity awareness? Will it work
> properly if it does not?
>
> ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
> >
> > Hi Igniters,
> >
> > Finally, all dependent tickets are resolved and I've completed the
> > implementation of thin client transactions support. The patch [1]
> includes
> > server-side implementation and java thin client-side implementation.
> > Changes to thin client protocol and top-level view of implementation also
> > described in IEP [2].
> > Can anyone review the patch?
> >
> > [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> > [2]:
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> > пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
> >
> > > Ivan,
> > >
> > > Yes, .NET client has such capability. Pavel Tupitsyn already mentions
> it
> > > in this thread. As far as I understand, in .NET client implementation
> to
> > > dispatch responses dedicated thread is used.
> > > In a draft implementation of IGNITE-11685 I've used another approach:
> each
> > > request thread can read a response (if lock is acquired by this thread
> > > successfully) and complete a future of its own request or another
> threads
> > > request.
> > >
> > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> > >
> > >> Alex,
> > >>
> > >> I am quite curious about async implementations from other clients. Is
> > >> there any design document describing such implementations? Does .NET
> > >> client have such capability?
> > >>
> > >> Actually, I forgot to finish my previous message. One of my concerns
> > >> is that a concurrent response dispatch does not sound as a trivial
> > >> thing. So, I would like to understand if we already have a good
> > >> approach for that. If not then I suppose it worth a discussion.
> > >>
> > >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
> > >> >
> > >> > Hi Ivan.
> > >> >
> > >> > Thin client transactions support is not only for java thin client.
> There
> > >> > are other clients, some of them already work in async mode.
> > >> > Ticket IGNITE-11685 already has draft implementation too, but now
> it's
> > >> > based on some changes to java thin client which were made by
> > >> "transaction
> > >> > support" implementation. I think this ticket will be ready in a
> couple
> > >> of
> > >> > days after "transaction support" will be merged. And both patches
> will
> > >> be
> > >> > included in the same release.
> > >> >
> > >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> > >> >
> > >> > > Hi Alex,
> > >> > >
> > >> > > Regarding a problem with possible deadlock when two concurrent
> > >> > > transactions from the same client are trying to lock the same key
> and
> > >> > > an issue [1]. It seems to me that without fixing the issue [1] a
> > >> > > client transactions feature is not practical. Everyone who uses a
> > >> > > client from multiple threads can face a deadlock which is
> impossible
> > >> > > to deal with. Or am I missing something here?
> > >> > >
> > >> > > One workaround I can imagine is failing a transactions execution
> from
> > >> > > concurrent threads for a first time.
> > >> > >
> > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> > >> > >
> > >> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov <
> plehanov.a...@gmail.com>:
> > >> > > >
> > >> > > > Guys,
> > >> > > >
> > >> > >

Re: Thin client: transactions support

[Павлухин Иван]

Hi Alex,

Could you please elaborate about thin client protocol versioning. As I
see 1.5.0 is supposed to be a version supporting transactions. And we
already have a version 1.4.0 with affinity awareness support. I
forgot, does Java thin client support affinity awareness? Will it work
properly if it does not?

ср, 14 авг. 2019 г. в 13:59, Alex Plehanov :
>
> Hi Igniters,
>
> Finally, all dependent tickets are resolved and I've completed the
> implementation of thin client transactions support. The patch [1] includes
> server-side implementation and java thin client-side implementation.
> Changes to thin client protocol and top-level view of implementation also
> described in IEP [2].
> Can anyone review the patch?
>
> [1]: https://issues.apache.org/jira/browse/IGNITE-9410
> [2]:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
> пн, 27 мая 2019 г. в 13:27, Alex Plehanov :
>
> > Ivan,
> >
> > Yes, .NET client has such capability. Pavel Tupitsyn already mentions it
> > in this thread. As far as I understand, in .NET client implementation to
> > dispatch responses dedicated thread is used.
> > In a draft implementation of IGNITE-11685 I've used another approach: each
> > request thread can read a response (if lock is acquired by this thread
> > successfully) and complete a future of its own request or another threads
> > request.
> >
> > пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
> >
> >> Alex,
> >>
> >> I am quite curious about async implementations from other clients. Is
> >> there any design document describing such implementations? Does .NET
> >> client have such capability?
> >>
> >> Actually, I forgot to finish my previous message. One of my concerns
> >> is that a concurrent response dispatch does not sound as a trivial
> >> thing. So, I would like to understand if we already have a good
> >> approach for that. If not then I suppose it worth a discussion.
> >>
> >> пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
> >> >
> >> > Hi Ivan.
> >> >
> >> > Thin client transactions support is not only for java thin client. There
> >> > are other clients, some of them already work in async mode.
> >> > Ticket IGNITE-11685 already has draft implementation too, but now it's
> >> > based on some changes to java thin client which were made by
> >> "transaction
> >> > support" implementation. I think this ticket will be ready in a couple
> >> of
> >> > days after "transaction support" will be merged. And both patches will
> >> be
> >> > included in the same release.
> >> >
> >> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> >> >
> >> > > Hi Alex,
> >> > >
> >> > > Regarding a problem with possible deadlock when two concurrent
> >> > > transactions from the same client are trying to lock the same key and
> >> > > an issue [1]. It seems to me that without fixing the issue [1] a
> >> > > client transactions feature is not practical. Everyone who uses a
> >> > > client from multiple threads can face a deadlock which is impossible
> >> > > to deal with. Or am I missing something here?
> >> > >
> >> > > One workaround I can imagine is failing a transactions execution from
> >> > > concurrent threads for a first time.
> >> > >
> >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> >> > >
> >> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
> >> > > >
> >> > > > Guys,
> >> > > >
> >> > > > I've updated the IEP [1]. Please have a look.
> >> > > >
> >> > > > [1]
> >> > > >
> >> > >
> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >> > > >
> >> > > >
> >> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov :
> >> > > >
> >> > > > > Ivan,
> >> > > > >
> >> > > > > Yes, I have plans to do that (at least for java thin client).
> >> Something
> >> > > > > like new class "ClientTransactionConfiguration" inside
> >> > > > > "ClientConfiguration".
> >> > > > >
> >> > > > > вт, 21 мая 20

Re: Thin client: transactions support

[Alex Plehanov]

Hi Igniters,

Finally, all dependent tickets are resolved and I've completed the
implementation of thin client transactions support. The patch [1] includes
server-side implementation and java thin client-side implementation.
Changes to thin client protocol and top-level view of implementation also
described in IEP [2].
Can anyone review the patch?

[1]: https://issues.apache.org/jira/browse/IGNITE-9410
[2]:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support

пн, 27 мая 2019 г. в 13:27, Alex Plehanov :

> Ivan,
>
> Yes, .NET client has such capability. Pavel Tupitsyn already mentions it
> in this thread. As far as I understand, in .NET client implementation to
> dispatch responses dedicated thread is used.
> In a draft implementation of IGNITE-11685 I've used another approach: each
> request thread can read a response (if lock is acquired by this thread
> successfully) and complete a future of its own request or another threads
> request.
>
> пн, 27 мая 2019 г. в 13:01, Павлухин Иван :
>
>> Alex,
>>
>> I am quite curious about async implementations from other clients. Is
>> there any design document describing such implementations? Does .NET
>> client have such capability?
>>
>> Actually, I forgot to finish my previous message. One of my concerns
>> is that a concurrent response dispatch does not sound as a trivial
>> thing. So, I would like to understand if we already have a good
>> approach for that. If not then I suppose it worth a discussion.
>>
>> пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
>> >
>> > Hi Ivan.
>> >
>> > Thin client transactions support is not only for java thin client. There
>> > are other clients, some of them already work in async mode.
>> > Ticket IGNITE-11685 already has draft implementation too, but now it's
>> > based on some changes to java thin client which were made by
>> "transaction
>> > support" implementation. I think this ticket will be ready in a couple
>> of
>> > days after "transaction support" will be merged. And both patches will
>> be
>> > included in the same release.
>> >
>> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
>> >
>> > > Hi Alex,
>> > >
>> > > Regarding a problem with possible deadlock when two concurrent
>> > > transactions from the same client are trying to lock the same key and
>> > > an issue [1]. It seems to me that without fixing the issue [1] a
>> > > client transactions feature is not practical. Everyone who uses a
>> > > client from multiple threads can face a deadlock which is impossible
>> > > to deal with. Or am I missing something here?
>> > >
>> > > One workaround I can imagine is failing a transactions execution from
>> > > concurrent threads for a first time.
>> > >
>> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
>> > >
>> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
>> > > >
>> > > > Guys,
>> > > >
>> > > > I've updated the IEP [1]. Please have a look.
>> > > >
>> > > > [1]
>> > > >
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > > >
>> > > >
>> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov :
>> > > >
>> > > > > Ivan,
>> > > > >
>> > > > > Yes, I have plans to do that (at least for java thin client).
>> Something
>> > > > > like new class "ClientTransactionConfiguration" inside
>> > > > > "ClientConfiguration".
>> > > > >
>> > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
>> > > > >
>> > > > >> Alex,
>> > > > >>
>> > > > >> Are you going to introduce settings specifying default values
>> for tx
>> > > > >> concurrency and isolation in client configuration?
>> > > > >>
>> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
>> plehanov.a...@gmail.com>:
>> > > > >> >
>> > > > >> > Igor,
>> > > > >> >
>> > > > >> > Perhaps we don't really need to use server's default values
>> for tx
>> > > > >> > parameters. It's a minor fix and can be easily implemented if
>

Re: Thin client: transactions support

[Alex Plehanov]

Ivan,

Yes, .NET client has such capability. Pavel Tupitsyn already mentions it in
this thread. As far as I understand, in .NET client implementation to
dispatch responses dedicated thread is used.
In a draft implementation of IGNITE-11685 I've used another approach: each
request thread can read a response (if lock is acquired by this thread
successfully) and complete a future of its own request or another threads
request.

пн, 27 мая 2019 г. в 13:01, Павлухин Иван :

> Alex,
>
> I am quite curious about async implementations from other clients. Is
> there any design document describing such implementations? Does .NET
> client have such capability?
>
> Actually, I forgot to finish my previous message. One of my concerns
> is that a concurrent response dispatch does not sound as a trivial
> thing. So, I would like to understand if we already have a good
> approach for that. If not then I suppose it worth a discussion.
>
> пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
> >
> > Hi Ivan.
> >
> > Thin client transactions support is not only for java thin client. There
> > are other clients, some of them already work in async mode.
> > Ticket IGNITE-11685 already has draft implementation too, but now it's
> > based on some changes to java thin client which were made by "transaction
> > support" implementation. I think this ticket will be ready in a couple of
> > days after "transaction support" will be merged. And both patches will be
> > included in the same release.
> >
> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
> >
> > > Hi Alex,
> > >
> > > Regarding a problem with possible deadlock when two concurrent
> > > transactions from the same client are trying to lock the same key and
> > > an issue [1]. It seems to me that without fixing the issue [1] a
> > > client transactions feature is not practical. Everyone who uses a
> > > client from multiple threads can face a deadlock which is impossible
> > > to deal with. Or am I missing something here?
> > >
> > > One workaround I can imagine is failing a transactions execution from
> > > concurrent threads for a first time.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> > >
> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
> > > >
> > > > Guys,
> > > >
> > > > I've updated the IEP [1]. Please have a look.
> > > >
> > > > [1]
> > > >
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > >
> > > >
> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov :
> > > >
> > > > > Ivan,
> > > > >
> > > > > Yes, I have plans to do that (at least for java thin client).
> Something
> > > > > like new class "ClientTransactionConfiguration" inside
> > > > > "ClientConfiguration".
> > > > >
> > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
> > > > >
> > > > >> Alex,
> > > > >>
> > > > >> Are you going to introduce settings specifying default values for
> tx
> > > > >> concurrency and isolation in client configuration?
> > > > >>
> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> plehanov.a...@gmail.com>:
> > > > >> >
> > > > >> > Igor,
> > > > >> >
> > > > >> > Perhaps we don't really need to use server's default values for
> tx
> > > > >> > parameters. It's a minor fix and can be easily implemented if it
> > > will be
> > > > >> > required in the future.
> > > > >> > I will update IEP tomorrow regarding point 1 and point 3.
> > > > >> > Thanks for your feedback.
> > > > >> >
> > > > >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> > > > >> >
> > > > >> > > Ivan,
> > > > >> > >
> > > > >> > > This may be a good point for a DBMS, but Ignite is much more
> than
> > > > >> just a
> > > > >> > > DBMS and Ignite client code is not just an SQL query (which
> > > execution
> > > > >> > > inherently heavily depends on DBMS). With database user is
> > > expecting
> > > > >> that
> > > > >> > > server have a

Re: Thin client: transactions support

[Павлухин Иван]

Alex,

I am quite curious about async implementations from other clients. Is
there any design document describing such implementations? Does .NET
client have such capability?

Actually, I forgot to finish my previous message. One of my concerns
is that a concurrent response dispatch does not sound as a trivial
thing. So, I would like to understand if we already have a good
approach for that. If not then I suppose it worth a discussion.

пн, 27 мая 2019 г. в 12:51, Alex Plehanov :
>
> Hi Ivan.
>
> Thin client transactions support is not only for java thin client. There
> are other clients, some of them already work in async mode.
> Ticket IGNITE-11685 already has draft implementation too, but now it's
> based on some changes to java thin client which were made by "transaction
> support" implementation. I think this ticket will be ready in a couple of
> days after "transaction support" will be merged. And both patches will be
> included in the same release.
>
> пн, 27 мая 2019 г. в 11:57, Павлухин Иван :
>
> > Hi Alex,
> >
> > Regarding a problem with possible deadlock when two concurrent
> > transactions from the same client are trying to lock the same key and
> > an issue [1]. It seems to me that without fixing the issue [1] a
> > client transactions feature is not practical. Everyone who uses a
> > client from multiple threads can face a deadlock which is impossible
> > to deal with. Or am I missing something here?
> >
> > One workaround I can imagine is failing a transactions execution from
> > concurrent threads for a first time.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> >
> > вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
> > >
> > > Guys,
> > >
> > > I've updated the IEP [1]. Please have a look.
> > >
> > > [1]
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >
> > >
> > > вт, 21 мая 2019 г., 14:19 Alex Plehanov :
> > >
> > > > Ivan,
> > > >
> > > > Yes, I have plans to do that (at least for java thin client). Something
> > > > like new class "ClientTransactionConfiguration" inside
> > > > "ClientConfiguration".
> > > >
> > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
> > > >
> > > >> Alex,
> > > >>
> > > >> Are you going to introduce settings specifying default values for tx
> > > >> concurrency and isolation in client configuration?
> > > >>
> > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
> > > >> >
> > > >> > Igor,
> > > >> >
> > > >> > Perhaps we don't really need to use server's default values for tx
> > > >> > parameters. It's a minor fix and can be easily implemented if it
> > will be
> > > >> > required in the future.
> > > >> > I will update IEP tomorrow regarding point 1 and point 3.
> > > >> > Thanks for your feedback.
> > > >> >
> > > >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> > > >> >
> > > >> > > Ivan,
> > > >> > >
> > > >> > > This may be a good point for a DBMS, but Ignite is much more than
> > > >> just a
> > > >> > > DBMS and Ignite client code is not just an SQL query (which
> > execution
> > > >> > > inherently heavily depends on DBMS). With database user is
> > expecting
> > > >> that
> > > >> > > server have a lot of control on query execution. But with Ignite,
> > in
> > > >> my
> > > >> > > opinion,
> > > >> > > user writes generic code including business logic in native
> > language
> > > >> and
> > > >> > > may
> > > >> > > expect more deterministic behaviour from a client.
> > > >> > >
> > > >> > > Also, thick clients do not use server-side defaults.
> > > >> > >
> > > >> > > Of course, this question is debatable and It's not like I 100%
> > against
> > > >> > > server-side
> > > >> > > defaults here, I just suggest to discuss it in more detail.
> > > >> > >
> > > >> > > Best Regards,
> > > >> > > Igor
> > > >> > >
> > &g

Re: Thin client: transactions support

[Alex Plehanov]

Hi Ivan.

Thin client transactions support is not only for java thin client. There
are other clients, some of them already work in async mode.
Ticket IGNITE-11685 already has draft implementation too, but now it's
based on some changes to java thin client which were made by "transaction
support" implementation. I think this ticket will be ready in a couple of
days after "transaction support" will be merged. And both patches will be
included in the same release.

пн, 27 мая 2019 г. в 11:57, Павлухин Иван :

> Hi Alex,
>
> Regarding a problem with possible deadlock when two concurrent
> transactions from the same client are trying to lock the same key and
> an issue [1]. It seems to me that without fixing the issue [1] a
> client transactions feature is not practical. Everyone who uses a
> client from multiple threads can face a deadlock which is impossible
> to deal with. Or am I missing something here?
>
> One workaround I can imagine is failing a transactions execution from
> concurrent threads for a first time.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11685
>
> вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
> >
> > Guys,
> >
> > I've updated the IEP [1]. Please have a look.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> >
> > вт, 21 мая 2019 г., 14:19 Alex Plehanov :
> >
> > > Ivan,
> > >
> > > Yes, I have plans to do that (at least for java thin client). Something
> > > like new class "ClientTransactionConfiguration" inside
> > > "ClientConfiguration".
> > >
> > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
> > >
> > >> Alex,
> > >>
> > >> Are you going to introduce settings specifying default values for tx
> > >> concurrency and isolation in client configuration?
> > >>
> > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
> > >> >
> > >> > Igor,
> > >> >
> > >> > Perhaps we don't really need to use server's default values for tx
> > >> > parameters. It's a minor fix and can be easily implemented if it
> will be
> > >> > required in the future.
> > >> > I will update IEP tomorrow regarding point 1 and point 3.
> > >> > Thanks for your feedback.
> > >> >
> > >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> > >> >
> > >> > > Ivan,
> > >> > >
> > >> > > This may be a good point for a DBMS, but Ignite is much more than
> > >> just a
> > >> > > DBMS and Ignite client code is not just an SQL query (which
> execution
> > >> > > inherently heavily depends on DBMS). With database user is
> expecting
> > >> that
> > >> > > server have a lot of control on query execution. But with Ignite,
> in
> > >> my
> > >> > > opinion,
> > >> > > user writes generic code including business logic in native
> language
> > >> and
> > >> > > may
> > >> > > expect more deterministic behaviour from a client.
> > >> > >
> > >> > > Also, thick clients do not use server-side defaults.
> > >> > >
> > >> > > Of course, this question is debatable and It's not like I 100%
> against
> > >> > > server-side
> > >> > > defaults here, I just suggest to discuss it in more detail.
> > >> > >
> > >> > > Best Regards,
> > >> > > Igor
> > >> > >
> > >> > >
> > >> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван <
> vololo...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > > Igor, Alex,
> > >> > > >
> > >> > > > Regarding point 1. I must say that SQL vendors usually allow to
> > >> > > > configure default timeouts and a transaction isolation on a
> server
> > >> > > > side. E.g. in MySQL you can do a following:
> > >> > > > set local tx_isolation =  -- per SQL client session
> > >> > > > (usually physical network connection)
> > >> > > > set global tx_isolation =  -- global settings, all
> > >> clients
> > >> > > > (which does not override it) are affected
> > >> > > >
> > >> > > &

Re: Thin client: transactions support

[Павлухин Иван]

Hi Alex,

Regarding a problem with possible deadlock when two concurrent
transactions from the same client are trying to lock the same key and
an issue [1]. It seems to me that without fixing the issue [1] a
client transactions feature is not practical. Everyone who uses a
client from multiple threads can face a deadlock which is impossible
to deal with. Or am I missing something here?

One workaround I can imagine is failing a transactions execution from
concurrent threads for a first time.

[1] https://issues.apache.org/jira/browse/IGNITE-11685

вт, 21 мая 2019 г. в 19:05, Alex Plehanov :
>
> Guys,
>
> I've updated the IEP [1]. Please have a look.
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
>
> вт, 21 мая 2019 г., 14:19 Alex Plehanov :
>
> > Ivan,
> >
> > Yes, I have plans to do that (at least for java thin client). Something
> > like new class "ClientTransactionConfiguration" inside
> > "ClientConfiguration".
> >
> > вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
> >
> >> Alex,
> >>
> >> Are you going to introduce settings specifying default values for tx
> >> concurrency and isolation in client configuration?
> >>
> >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
> >> >
> >> > Igor,
> >> >
> >> > Perhaps we don't really need to use server's default values for tx
> >> > parameters. It's a minor fix and can be easily implemented if it will be
> >> > required in the future.
> >> > I will update IEP tomorrow regarding point 1 and point 3.
> >> > Thanks for your feedback.
> >> >
> >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> >> >
> >> > > Ivan,
> >> > >
> >> > > This may be a good point for a DBMS, but Ignite is much more than
> >> just a
> >> > > DBMS and Ignite client code is not just an SQL query (which execution
> >> > > inherently heavily depends on DBMS). With database user is expecting
> >> that
> >> > > server have a lot of control on query execution. But with Ignite, in
> >> my
> >> > > opinion,
> >> > > user writes generic code including business logic in native language
> >> and
> >> > > may
> >> > > expect more deterministic behaviour from a client.
> >> > >
> >> > > Also, thick clients do not use server-side defaults.
> >> > >
> >> > > Of course, this question is debatable and It's not like I 100% against
> >> > > server-side
> >> > > defaults here, I just suggest to discuss it in more detail.
> >> > >
> >> > > Best Regards,
> >> > > Igor
> >> > >
> >> > >
> >> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван 
> >> wrote:
> >> > >
> >> > > > Igor, Alex,
> >> > > >
> >> > > > Regarding point 1. I must say that SQL vendors usually allow to
> >> > > > configure default timeouts and a transaction isolation on a server
> >> > > > side. E.g. in MySQL you can do a following:
> >> > > > set local tx_isolation =  -- per SQL client session
> >> > > > (usually physical network connection)
> >> > > > set global tx_isolation =  -- global settings, all
> >> clients
> >> > > > (which does not override it) are affected
> >> > > >
> >> > > > So, if it is a standard practice why should do it differently? If it
> >> > > > is not, we can continue discussion. Do we have some examples
> >> following
> >> > > > opposite way (client-wide default setting)?
> >> > > >
> >> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> >> > > > >
> >> > > > > 1. In my opinion, having client-specific transaction parameters is
> >> > > > expected
> >> > > > > for
> >> > > > > client when have different arguments depending on server seems
> >> > > unexpected
> >> > > > > and can lead to hard-to-debug bugs and issues when updating from
> >> old to
> >> > > > new
> >> > > > > server versions. Also it goes against common practice with
> >> arguments of
> >> > > > thin
> >> > > > > client and thus, may be even more unexpected.
> >> > > > >
> >> > > > > I believe that if we want to add ability to client to adopt some
> >> > > server's
> >> > > > > defaults
> >> > > > > we should implement it as separate feature, and it should not be a
> >> > > > default
> >> > > > > behaviour for client, user should explicitly state that they want
> >> this
> >> > > > > behaviour,
> >> > > > > so it won't be unexpected for them.
> >> > > > >
> >> > > > > 3. "Flags" field looks like a good solution to me.
> >> > > > >
> >> > > > > Best Regards,
> >> > > > > Igor
> >> > > > >
> >> > > > >
> >> > > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
> >> > > plehanov.a...@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Hi, Igor
> >> > > > > >
> >> > > > > > 1. I think it's better to have the ability to configure
> >> transaction
> >> > > > > > parameters (for example configure default timeout for all
> >> clients) on
> >> > > > > > server-side, then don't have such ability and always use some
> >> > > > predefined
> >> > > > > > client-side values (which can be different for different client
> >> > > > > > implementations). At least default timeout is more server
> >> specific
> >> > > 

Re: Thin client: transactions support

[Alex Plehanov]

Guys,

I've updated the IEP [1]. Please have a look.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support


вт, 21 мая 2019 г., 14:19 Alex Plehanov :

> Ivan,
>
> Yes, I have plans to do that (at least for java thin client). Something
> like new class "ClientTransactionConfiguration" inside
> "ClientConfiguration".
>
> вт, 21 мая 2019 г. в 13:37, Павлухин Иван :
>
>> Alex,
>>
>> Are you going to introduce settings specifying default values for tx
>> concurrency and isolation in client configuration?
>>
>> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
>> >
>> > Igor,
>> >
>> > Perhaps we don't really need to use server's default values for tx
>> > parameters. It's a minor fix and can be easily implemented if it will be
>> > required in the future.
>> > I will update IEP tomorrow regarding point 1 and point 3.
>> > Thanks for your feedback.
>> >
>> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
>> >
>> > > Ivan,
>> > >
>> > > This may be a good point for a DBMS, but Ignite is much more than
>> just a
>> > > DBMS and Ignite client code is not just an SQL query (which execution
>> > > inherently heavily depends on DBMS). With database user is expecting
>> that
>> > > server have a lot of control on query execution. But with Ignite, in
>> my
>> > > opinion,
>> > > user writes generic code including business logic in native language
>> and
>> > > may
>> > > expect more deterministic behaviour from a client.
>> > >
>> > > Also, thick clients do not use server-side defaults.
>> > >
>> > > Of course, this question is debatable and It's not like I 100% against
>> > > server-side
>> > > defaults here, I just suggest to discuss it in more detail.
>> > >
>> > > Best Regards,
>> > > Igor
>> > >
>> > >
>> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван 
>> wrote:
>> > >
>> > > > Igor, Alex,
>> > > >
>> > > > Regarding point 1. I must say that SQL vendors usually allow to
>> > > > configure default timeouts and a transaction isolation on a server
>> > > > side. E.g. in MySQL you can do a following:
>> > > > set local tx_isolation =  -- per SQL client session
>> > > > (usually physical network connection)
>> > > > set global tx_isolation =  -- global settings, all
>> clients
>> > > > (which does not override it) are affected
>> > > >
>> > > > So, if it is a standard practice why should do it differently? If it
>> > > > is not, we can continue discussion. Do we have some examples
>> following
>> > > > opposite way (client-wide default setting)?
>> > > >
>> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
>> > > > >
>> > > > > 1. In my opinion, having client-specific transaction parameters is
>> > > > expected
>> > > > > for
>> > > > > client when have different arguments depending on server seems
>> > > unexpected
>> > > > > and can lead to hard-to-debug bugs and issues when updating from
>> old to
>> > > > new
>> > > > > server versions. Also it goes against common practice with
>> arguments of
>> > > > thin
>> > > > > client and thus, may be even more unexpected.
>> > > > >
>> > > > > I believe that if we want to add ability to client to adopt some
>> > > server's
>> > > > > defaults
>> > > > > we should implement it as separate feature, and it should not be a
>> > > > default
>> > > > > behaviour for client, user should explicitly state that they want
>> this
>> > > > > behaviour,
>> > > > > so it won't be unexpected for them.
>> > > > >
>> > > > > 3. "Flags" field looks like a good solution to me.
>> > > > >
>> > > > > Best Regards,
>> > > > > Igor
>> > > > >
>> > > > >
>> > > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
>> > > plehanov.a...@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > Hi, Igor
>> > > > > >
>> > > > > > 1. I think it's better to have the ability to configure
>> transaction
>> > > > > > parameters (for example configure default timeout for all
>> clients) on
>> > > > > > server-side, then don't have such ability and always use some
>> > > > predefined
>> > > > > > client-side values (which can be different for different client
>> > > > > > implementations). At least default timeout is more server
>> specific
>> > > then
>> > > > > > client specific parameter since it can affect server-side
>> processes
>> > > > (PME
>> > > > > > for example).
>> > > > > >
>> > > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be
>> included to
>> > > > each
>> > > > > > cache operation under a transaction. And it almost will not
>> simplify
>> > > > server
>> > > > > > code. Also, thin clients don't know how to deal with IgniteUuid
>> now,
>> > > > there
>> > > > > > is no such entity in the protocol, there are no described rules
>> on
>> > > how
>> > > > to
>> > > > > > convert it to a string. For monitoring/debugging purposes we
>> should
>> > > > have
>> > > > > > the same presentation of this entity on server and client
>> sides. I
>> > > > think if
>> > > > > > we need to know real tx id on the client side it's better to
>> > > > additionally
>> 

Re: Thin client: transactions support

[Alex Plehanov]

Ivan,

Yes, I have plans to do that (at least for java thin client). Something
like new class "ClientTransactionConfiguration" inside
"ClientConfiguration".

вт, 21 мая 2019 г. в 13:37, Павлухин Иван :

> Alex,
>
> Are you going to introduce settings specifying default values for tx
> concurrency and isolation in client configuration?
>
> пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
> >
> > Igor,
> >
> > Perhaps we don't really need to use server's default values for tx
> > parameters. It's a minor fix and can be easily implemented if it will be
> > required in the future.
> > I will update IEP tomorrow regarding point 1 and point 3.
> > Thanks for your feedback.
> >
> > пн, 20 мая 2019 г. в 15:24, Igor Sapego :
> >
> > > Ivan,
> > >
> > > This may be a good point for a DBMS, but Ignite is much more than just
> a
> > > DBMS and Ignite client code is not just an SQL query (which execution
> > > inherently heavily depends on DBMS). With database user is expecting
> that
> > > server have a lot of control on query execution. But with Ignite, in my
> > > opinion,
> > > user writes generic code including business logic in native language
> and
> > > may
> > > expect more deterministic behaviour from a client.
> > >
> > > Also, thick clients do not use server-side defaults.
> > >
> > > Of course, this question is debatable and It's not like I 100% against
> > > server-side
> > > defaults here, I just suggest to discuss it in more detail.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван 
> wrote:
> > >
> > > > Igor, Alex,
> > > >
> > > > Regarding point 1. I must say that SQL vendors usually allow to
> > > > configure default timeouts and a transaction isolation on a server
> > > > side. E.g. in MySQL you can do a following:
> > > > set local tx_isolation =  -- per SQL client session
> > > > (usually physical network connection)
> > > > set global tx_isolation =  -- global settings, all clients
> > > > (which does not override it) are affected
> > > >
> > > > So, if it is a standard practice why should do it differently? If it
> > > > is not, we can continue discussion. Do we have some examples
> following
> > > > opposite way (client-wide default setting)?
> > > >
> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> > > > >
> > > > > 1. In my opinion, having client-specific transaction parameters is
> > > > expected
> > > > > for
> > > > > client when have different arguments depending on server seems
> > > unexpected
> > > > > and can lead to hard-to-debug bugs and issues when updating from
> old to
> > > > new
> > > > > server versions. Also it goes against common practice with
> arguments of
> > > > thin
> > > > > client and thus, may be even more unexpected.
> > > > >
> > > > > I believe that if we want to add ability to client to adopt some
> > > server's
> > > > > defaults
> > > > > we should implement it as separate feature, and it should not be a
> > > > default
> > > > > behaviour for client, user should explicitly state that they want
> this
> > > > > behaviour,
> > > > > so it won't be unexpected for them.
> > > > >
> > > > > 3. "Flags" field looks like a good solution to me.
> > > > >
> > > > > Best Regards,
> > > > > Igor
> > > > >
> > > > >
> > > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
> > > plehanov.a...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi, Igor
> > > > > >
> > > > > > 1. I think it's better to have the ability to configure
> transaction
> > > > > > parameters (for example configure default timeout for all
> clients) on
> > > > > > server-side, then don't have such ability and always use some
> > > > predefined
> > > > > > client-side values (which can be different for different client
> > > > > > implementations). At least default timeout is more server
> specific
> > > then
> > > > > > client specific parameter since it can affect server-side
> processes
> > > > (PME
> > > > > > for example).
> > > > > >
> > > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be
> included to
> > > > each
> > > > > > cache operation under a transaction. And it almost will not
> simplify
> > > > server
> > > > > > code. Also, thin clients don't know how to deal with IgniteUuid
> now,
> > > > there
> > > > > > is no such entity in the protocol, there are no described rules
> on
> > > how
> > > > to
> > > > > > convert it to a string. For monitoring/debugging purposes we
> should
> > > > have
> > > > > > the same presentation of this entity on server and client sides.
> I
> > > > think if
> > > > > > we need to know real tx id on the client side it's better to
> > > > additionally
> > > > > > include this value to OP_TX_START response (we also can
> serialize it
> > > > as a
> > > > > > string to avoid introducing new entity on client side) or create
> a
> > > new
> > > > > > operation to explicitly request tx id (for example OP_TX_INFO).
> > > > > >
> > > > > > 3. Make sense, we can reuse deprecated "flags" field 

Re: Thin client: transactions support

[Павлухин Иван]

Alex,

Are you going to introduce settings specifying default values for tx
concurrency and isolation in client configuration?

пн, 20 мая 2019 г. в 19:34, Alex Plehanov :
>
> Igor,
>
> Perhaps we don't really need to use server's default values for tx
> parameters. It's a minor fix and can be easily implemented if it will be
> required in the future.
> I will update IEP tomorrow regarding point 1 and point 3.
> Thanks for your feedback.
>
> пн, 20 мая 2019 г. в 15:24, Igor Sapego :
>
> > Ivan,
> >
> > This may be a good point for a DBMS, but Ignite is much more than just a
> > DBMS and Ignite client code is not just an SQL query (which execution
> > inherently heavily depends on DBMS). With database user is expecting that
> > server have a lot of control on query execution. But with Ignite, in my
> > opinion,
> > user writes generic code including business logic in native language and
> > may
> > expect more deterministic behaviour from a client.
> >
> > Also, thick clients do not use server-side defaults.
> >
> > Of course, this question is debatable and It's not like I 100% against
> > server-side
> > defaults here, I just suggest to discuss it in more detail.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван  wrote:
> >
> > > Igor, Alex,
> > >
> > > Regarding point 1. I must say that SQL vendors usually allow to
> > > configure default timeouts and a transaction isolation on a server
> > > side. E.g. in MySQL you can do a following:
> > > set local tx_isolation =  -- per SQL client session
> > > (usually physical network connection)
> > > set global tx_isolation =  -- global settings, all clients
> > > (which does not override it) are affected
> > >
> > > So, if it is a standard practice why should do it differently? If it
> > > is not, we can continue discussion. Do we have some examples following
> > > opposite way (client-wide default setting)?
> > >
> > > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> > > >
> > > > 1. In my opinion, having client-specific transaction parameters is
> > > expected
> > > > for
> > > > client when have different arguments depending on server seems
> > unexpected
> > > > and can lead to hard-to-debug bugs and issues when updating from old to
> > > new
> > > > server versions. Also it goes against common practice with arguments of
> > > thin
> > > > client and thus, may be even more unexpected.
> > > >
> > > > I believe that if we want to add ability to client to adopt some
> > server's
> > > > defaults
> > > > we should implement it as separate feature, and it should not be a
> > > default
> > > > behaviour for client, user should explicitly state that they want this
> > > > behaviour,
> > > > so it won't be unexpected for them.
> > > >
> > > > 3. "Flags" field looks like a good solution to me.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
> > plehanov.a...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi, Igor
> > > > >
> > > > > 1. I think it's better to have the ability to configure transaction
> > > > > parameters (for example configure default timeout for all clients) on
> > > > > server-side, then don't have such ability and always use some
> > > predefined
> > > > > client-side values (which can be different for different client
> > > > > implementations). At least default timeout is more server specific
> > then
> > > > > client specific parameter since it can affect server-side processes
> > > (PME
> > > > > for example).
> > > > >
> > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be included to
> > > each
> > > > > cache operation under a transaction. And it almost will not simplify
> > > server
> > > > > code. Also, thin clients don't know how to deal with IgniteUuid now,
> > > there
> > > > > is no such entity in the protocol, there are no described rules on
> > how
> > > to
> > > > > convert it to a string. For monitoring/debugging purposes we should
> > > have
> > > > > the same presentation of this entity on server and client sides. I
> > > think if
> > > > > we need to know real tx id on the client side it's better to
> > > additionally
> > > > > include this value to OP_TX_START response (we also can serialize it
> > > as a
> > > > > string to avoid introducing new entity on client side) or create a
> > new
> > > > > operation to explicitly request tx id (for example OP_TX_INFO).
> > > > >
> > > > > 3. Make sense, we can reuse deprecated "flags" field (undeprecate
> > it),
> > > > > which is included now to each cache operation.
> > > > >
> > > > >
> > > > > пт, 17 мая 2019 г. в 18:49, Igor Sapego :
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I had a look at IEP and have several comments:
> > > > > >
> > > > > > 1. Why would one want to use to use server's default values for
> > > > > Concurrency
> > > > > > or Isolation?
> > > > > > I believe, client should have its own defaults which should be
> > > explicitly
> > > > > > 

Re: Thin client: transactions support

[Alex Plehanov]

Igor,

Perhaps we don't really need to use server's default values for tx
parameters. It's a minor fix and can be easily implemented if it will be
required in the future.
I will update IEP tomorrow regarding point 1 and point 3.
Thanks for your feedback.

пн, 20 мая 2019 г. в 15:24, Igor Sapego :

> Ivan,
>
> This may be a good point for a DBMS, but Ignite is much more than just a
> DBMS and Ignite client code is not just an SQL query (which execution
> inherently heavily depends on DBMS). With database user is expecting that
> server have a lot of control on query execution. But with Ignite, in my
> opinion,
> user writes generic code including business logic in native language and
> may
> expect more deterministic behaviour from a client.
>
> Also, thick clients do not use server-side defaults.
>
> Of course, this question is debatable and It's not like I 100% against
> server-side
> defaults here, I just suggest to discuss it in more detail.
>
> Best Regards,
> Igor
>
>
> On Mon, May 20, 2019 at 2:21 PM Павлухин Иван  wrote:
>
> > Igor, Alex,
> >
> > Regarding point 1. I must say that SQL vendors usually allow to
> > configure default timeouts and a transaction isolation on a server
> > side. E.g. in MySQL you can do a following:
> > set local tx_isolation =  -- per SQL client session
> > (usually physical network connection)
> > set global tx_isolation =  -- global settings, all clients
> > (which does not override it) are affected
> >
> > So, if it is a standard practice why should do it differently? If it
> > is not, we can continue discussion. Do we have some examples following
> > opposite way (client-wide default setting)?
> >
> > пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> > >
> > > 1. In my opinion, having client-specific transaction parameters is
> > expected
> > > for
> > > client when have different arguments depending on server seems
> unexpected
> > > and can lead to hard-to-debug bugs and issues when updating from old to
> > new
> > > server versions. Also it goes against common practice with arguments of
> > thin
> > > client and thus, may be even more unexpected.
> > >
> > > I believe that if we want to add ability to client to adopt some
> server's
> > > defaults
> > > we should implement it as separate feature, and it should not be a
> > default
> > > behaviour for client, user should explicitly state that they want this
> > > behaviour,
> > > so it won't be unexpected for them.
> > >
> > > 3. "Flags" field looks like a good solution to me.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
> plehanov.a...@gmail.com>
> > > wrote:
> > >
> > > > Hi, Igor
> > > >
> > > > 1. I think it's better to have the ability to configure transaction
> > > > parameters (for example configure default timeout for all clients) on
> > > > server-side, then don't have such ability and always use some
> > predefined
> > > > client-side values (which can be different for different client
> > > > implementations). At least default timeout is more server specific
> then
> > > > client specific parameter since it can affect server-side processes
> > (PME
> > > > for example).
> > > >
> > > > 2. IgniteUuid has 24 bytes length. This tx id needs to be included to
> > each
> > > > cache operation under a transaction. And it almost will not simplify
> > server
> > > > code. Also, thin clients don't know how to deal with IgniteUuid now,
> > there
> > > > is no such entity in the protocol, there are no described rules on
> how
> > to
> > > > convert it to a string. For monitoring/debugging purposes we should
> > have
> > > > the same presentation of this entity on server and client sides. I
> > think if
> > > > we need to know real tx id on the client side it's better to
> > additionally
> > > > include this value to OP_TX_START response (we also can serialize it
> > as a
> > > > string to avoid introducing new entity on client side) or create a
> new
> > > > operation to explicitly request tx id (for example OP_TX_INFO).
> > > >
> > > > 3. Make sense, we can reuse deprecated "flags" field (undeprecate
> it),
> > > > which is included now to each cache operation.
> > > >
> > > >
> > > > пт, 17 мая 2019 г. в 18:49, Igor Sapego :
> > > >
> > > > > Hi,
> > > > >
> > > > > I had a look at IEP and have several comments:
> > > > >
> > > > > 1. Why would one want to use to use server's default values for
> > > > Concurrency
> > > > > or Isolation?
> > > > > I believe, client should have its own defaults which should be
> > explicitly
> > > > > documented, so that
> > > > > behaviour of transactions will not depend on the server node it was
> > > > routed
> > > > > to. The same goes
> > > > > for timeout.
> > > > >
> > > > > 2. Not sure about transaction ID represented by int. Why not to use
> > > > > IgniteUuid? It should simplify
> > > > > server code. Also it may help with monitoring/debugging if thin
> > clients
> > > > and
> > > > > server nodes use the
> > > > > same 

Re: Thin client: transactions support

[Igor Sapego]

Ivan,

This may be a good point for a DBMS, but Ignite is much more than just a
DBMS and Ignite client code is not just an SQL query (which execution
inherently heavily depends on DBMS). With database user is expecting that
server have a lot of control on query execution. But with Ignite, in my
opinion,
user writes generic code including business logic in native language and may
expect more deterministic behaviour from a client.

Also, thick clients do not use server-side defaults.

Of course, this question is debatable and It's not like I 100% against
server-side
defaults here, I just suggest to discuss it in more detail.

Best Regards,
Igor


On Mon, May 20, 2019 at 2:21 PM Павлухин Иван  wrote:

> Igor, Alex,
>
> Regarding point 1. I must say that SQL vendors usually allow to
> configure default timeouts and a transaction isolation on a server
> side. E.g. in MySQL you can do a following:
> set local tx_isolation =  -- per SQL client session
> (usually physical network connection)
> set global tx_isolation =  -- global settings, all clients
> (which does not override it) are affected
>
> So, if it is a standard practice why should do it differently? If it
> is not, we can continue discussion. Do we have some examples following
> opposite way (client-wide default setting)?
>
> пн, 20 мая 2019 г. в 13:50, Igor Sapego :
> >
> > 1. In my opinion, having client-specific transaction parameters is
> expected
> > for
> > client when have different arguments depending on server seems unexpected
> > and can lead to hard-to-debug bugs and issues when updating from old to
> new
> > server versions. Also it goes against common practice with arguments of
> thin
> > client and thus, may be even more unexpected.
> >
> > I believe that if we want to add ability to client to adopt some server's
> > defaults
> > we should implement it as separate feature, and it should not be a
> default
> > behaviour for client, user should explicitly state that they want this
> > behaviour,
> > so it won't be unexpected for them.
> >
> > 3. "Flags" field looks like a good solution to me.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov 
> > wrote:
> >
> > > Hi, Igor
> > >
> > > 1. I think it's better to have the ability to configure transaction
> > > parameters (for example configure default timeout for all clients) on
> > > server-side, then don't have such ability and always use some
> predefined
> > > client-side values (which can be different for different client
> > > implementations). At least default timeout is more server specific then
> > > client specific parameter since it can affect server-side processes
> (PME
> > > for example).
> > >
> > > 2. IgniteUuid has 24 bytes length. This tx id needs to be included to
> each
> > > cache operation under a transaction. And it almost will not simplify
> server
> > > code. Also, thin clients don't know how to deal with IgniteUuid now,
> there
> > > is no such entity in the protocol, there are no described rules on how
> to
> > > convert it to a string. For monitoring/debugging purposes we should
> have
> > > the same presentation of this entity on server and client sides. I
> think if
> > > we need to know real tx id on the client side it's better to
> additionally
> > > include this value to OP_TX_START response (we also can serialize it
> as a
> > > string to avoid introducing new entity on client side) or create a new
> > > operation to explicitly request tx id (for example OP_TX_INFO).
> > >
> > > 3. Make sense, we can reuse deprecated "flags" field (undeprecate it),
> > > which is included now to each cache operation.
> > >
> > >
> > > пт, 17 мая 2019 г. в 18:49, Igor Sapego :
> > >
> > > > Hi,
> > > >
> > > > I had a look at IEP and have several comments:
> > > >
> > > > 1. Why would one want to use to use server's default values for
> > > Concurrency
> > > > or Isolation?
> > > > I believe, client should have its own defaults which should be
> explicitly
> > > > documented, so that
> > > > behaviour of transactions will not depend on the server node it was
> > > routed
> > > > to. The same goes
> > > > for timeout.
> > > >
> > > > 2. Not sure about transaction ID represented by int. Why not to use
> > > > IgniteUuid? It should simplify
> > > > server code. Also it may help with monitoring/debugging if thin
> clients
> > > and
> > > > server nodes use the
> > > > same identifier for transactions. It does not seem as a big overhead
> to
> > > me
> > > > either.
> > > >
> > > > 3. Maybe it makes sense to add "In transaction" boolean flag to cache
> > > > operation request header
> > > > to avoid bloating message size in non-affected scenarios.
> > > >
> > > > Best Regards,
> > > > Igor
> > > >
> > > >
> > > > On Mon, May 13, 2019 at 1:58 PM Alex Plehanov <
> plehanov.a...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi, Ivan.
> > > > >
> > > > > Thanks for your comments.
> > > > >
> > > > > 1. Transaction id in thin client protocol it's just 

Re: Thin client: transactions support

[Павлухин Иван]

Igor, Alex,

Regarding point 1. I must say that SQL vendors usually allow to
configure default timeouts and a transaction isolation on a server
side. E.g. in MySQL you can do a following:
set local tx_isolation =  -- per SQL client session
(usually physical network connection)
set global tx_isolation =  -- global settings, all clients
(which does not override it) are affected

So, if it is a standard practice why should do it differently? If it
is not, we can continue discussion. Do we have some examples following
opposite way (client-wide default setting)?

пн, 20 мая 2019 г. в 13:50, Igor Sapego :
>
> 1. In my opinion, having client-specific transaction parameters is expected
> for
> client when have different arguments depending on server seems unexpected
> and can lead to hard-to-debug bugs and issues when updating from old to new
> server versions. Also it goes against common practice with arguments of thin
> client and thus, may be even more unexpected.
>
> I believe that if we want to add ability to client to adopt some server's
> defaults
> we should implement it as separate feature, and it should not be a default
> behaviour for client, user should explicitly state that they want this
> behaviour,
> so it won't be unexpected for them.
>
> 3. "Flags" field looks like a good solution to me.
>
> Best Regards,
> Igor
>
>
> On Mon, May 20, 2019 at 12:58 PM Alex Plehanov 
> wrote:
>
> > Hi, Igor
> >
> > 1. I think it's better to have the ability to configure transaction
> > parameters (for example configure default timeout for all clients) on
> > server-side, then don't have such ability and always use some predefined
> > client-side values (which can be different for different client
> > implementations). At least default timeout is more server specific then
> > client specific parameter since it can affect server-side processes (PME
> > for example).
> >
> > 2. IgniteUuid has 24 bytes length. This tx id needs to be included to each
> > cache operation under a transaction. And it almost will not simplify server
> > code. Also, thin clients don't know how to deal with IgniteUuid now, there
> > is no such entity in the protocol, there are no described rules on how to
> > convert it to a string. For monitoring/debugging purposes we should have
> > the same presentation of this entity on server and client sides. I think if
> > we need to know real tx id on the client side it's better to additionally
> > include this value to OP_TX_START response (we also can serialize it as a
> > string to avoid introducing new entity on client side) or create a new
> > operation to explicitly request tx id (for example OP_TX_INFO).
> >
> > 3. Make sense, we can reuse deprecated "flags" field (undeprecate it),
> > which is included now to each cache operation.
> >
> >
> > пт, 17 мая 2019 г. в 18:49, Igor Sapego :
> >
> > > Hi,
> > >
> > > I had a look at IEP and have several comments:
> > >
> > > 1. Why would one want to use to use server's default values for
> > Concurrency
> > > or Isolation?
> > > I believe, client should have its own defaults which should be explicitly
> > > documented, so that
> > > behaviour of transactions will not depend on the server node it was
> > routed
> > > to. The same goes
> > > for timeout.
> > >
> > > 2. Not sure about transaction ID represented by int. Why not to use
> > > IgniteUuid? It should simplify
> > > server code. Also it may help with monitoring/debugging if thin clients
> > and
> > > server nodes use the
> > > same identifier for transactions. It does not seem as a big overhead to
> > me
> > > either.
> > >
> > > 3. Maybe it makes sense to add "In transaction" boolean flag to cache
> > > operation request header
> > > to avoid bloating message size in non-affected scenarios.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Mon, May 13, 2019 at 1:58 PM Alex Plehanov 
> > > wrote:
> > >
> > > > Hi, Ivan.
> > > >
> > > > Thanks for your comments.
> > > >
> > > > 1. Transaction id in thin client protocol it's just a tx counter for
> > the
> > > > current connection. It's not related to GridCacheVersion. If we want to
> > > > know GridCacheVersion on the client side, I think we should introduce a
> > > new
> > > > type of operation (for example OP_TX_INFO).
> > > > 2. Error handling is already provided by thin client protocol, even in
> > > case
> > > > of empty response. Of course, the client will know if there is a
> > failure
> > > > occurred during OP_TX_END operation.
> > > > 3. AFAIK some of thin client implementations already send requests and
> > > > process responses in an async way (.NET for example). As for java thin
> > > > client, in the current implementation channel is locked exclusively
> > > before
> > > > request send and until the response is processed. I have some ideas
> > about
> > > > how to fix this (split send/receive process into two different parts
> > and
> > > > acquire locks for this parts separately or create futures on request
> > sent
> > > 

Re: Thin client: transactions support

[Igor Sapego]

1. In my opinion, having client-specific transaction parameters is expected
for
client when have different arguments depending on server seems unexpected
and can lead to hard-to-debug bugs and issues when updating from old to new
server versions. Also it goes against common practice with arguments of thin
client and thus, may be even more unexpected.

I believe that if we want to add ability to client to adopt some server's
defaults
we should implement it as separate feature, and it should not be a default
behaviour for client, user should explicitly state that they want this
behaviour,
so it won't be unexpected for them.

3. "Flags" field looks like a good solution to me.

Best Regards,
Igor


On Mon, May 20, 2019 at 12:58 PM Alex Plehanov 
wrote:

> Hi, Igor
>
> 1. I think it's better to have the ability to configure transaction
> parameters (for example configure default timeout for all clients) on
> server-side, then don't have such ability and always use some predefined
> client-side values (which can be different for different client
> implementations). At least default timeout is more server specific then
> client specific parameter since it can affect server-side processes (PME
> for example).
>
> 2. IgniteUuid has 24 bytes length. This tx id needs to be included to each
> cache operation under a transaction. And it almost will not simplify server
> code. Also, thin clients don't know how to deal with IgniteUuid now, there
> is no such entity in the protocol, there are no described rules on how to
> convert it to a string. For monitoring/debugging purposes we should have
> the same presentation of this entity on server and client sides. I think if
> we need to know real tx id on the client side it's better to additionally
> include this value to OP_TX_START response (we also can serialize it as a
> string to avoid introducing new entity on client side) or create a new
> operation to explicitly request tx id (for example OP_TX_INFO).
>
> 3. Make sense, we can reuse deprecated "flags" field (undeprecate it),
> which is included now to each cache operation.
>
>
> пт, 17 мая 2019 г. в 18:49, Igor Sapego :
>
> > Hi,
> >
> > I had a look at IEP and have several comments:
> >
> > 1. Why would one want to use to use server's default values for
> Concurrency
> > or Isolation?
> > I believe, client should have its own defaults which should be explicitly
> > documented, so that
> > behaviour of transactions will not depend on the server node it was
> routed
> > to. The same goes
> > for timeout.
> >
> > 2. Not sure about transaction ID represented by int. Why not to use
> > IgniteUuid? It should simplify
> > server code. Also it may help with monitoring/debugging if thin clients
> and
> > server nodes use the
> > same identifier for transactions. It does not seem as a big overhead to
> me
> > either.
> >
> > 3. Maybe it makes sense to add "In transaction" boolean flag to cache
> > operation request header
> > to avoid bloating message size in non-affected scenarios.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Mon, May 13, 2019 at 1:58 PM Alex Plehanov 
> > wrote:
> >
> > > Hi, Ivan.
> > >
> > > Thanks for your comments.
> > >
> > > 1. Transaction id in thin client protocol it's just a tx counter for
> the
> > > current connection. It's not related to GridCacheVersion. If we want to
> > > know GridCacheVersion on the client side, I think we should introduce a
> > new
> > > type of operation (for example OP_TX_INFO).
> > > 2. Error handling is already provided by thin client protocol, even in
> > case
> > > of empty response. Of course, the client will know if there is a
> failure
> > > occurred during OP_TX_END operation.
> > > 3. AFAIK some of thin client implementations already send requests and
> > > process responses in an async way (.NET for example). As for java thin
> > > client, in the current implementation channel is locked exclusively
> > before
> > > request send and until the response is processed. I have some ideas
> about
> > > how to fix this (split send/receive process into two different parts
> and
> > > acquire locks for this parts separately or create futures on request
> sent
> > > and complete it after processing the response in a dedicated thread),
> > I've
> > > created ticket [1] for this issue and will try to implement prototype
> in
> > a
> > > couple of days.
> > >
> > > About suspend/resume, yes, on server-side we should resume tx before
> each
> > > transactional cache operation and suspend the tx after the operation.
> In
> > my
> > > opinion, suspend/resume approach have several advantages over approach
> > with
> > > explicit tx id argument:
> > > - Introducing explicit tx id argument for cache operations leads to a
> > > significant API change
> > > - It's not clear how to use it together with current (tx-per-thread)
> > > approach (for example, what if a thread is already held transaction and
> > > someone call cache operation with explicit tx id?)
> > > - Suspend/resume 

Re: Thin client: transactions support

[Alex Plehanov]

Hi, Igor

1. I think it's better to have the ability to configure transaction
parameters (for example configure default timeout for all clients) on
server-side, then don't have such ability and always use some predefined
client-side values (which can be different for different client
implementations). At least default timeout is more server specific then
client specific parameter since it can affect server-side processes (PME
for example).

2. IgniteUuid has 24 bytes length. This tx id needs to be included to each
cache operation under a transaction. And it almost will not simplify server
code. Also, thin clients don't know how to deal with IgniteUuid now, there
is no such entity in the protocol, there are no described rules on how to
convert it to a string. For monitoring/debugging purposes we should have
the same presentation of this entity on server and client sides. I think if
we need to know real tx id on the client side it's better to additionally
include this value to OP_TX_START response (we also can serialize it as a
string to avoid introducing new entity on client side) or create a new
operation to explicitly request tx id (for example OP_TX_INFO).

3. Make sense, we can reuse deprecated "flags" field (undeprecate it),
which is included now to each cache operation.


пт, 17 мая 2019 г. в 18:49, Igor Sapego :

> Hi,
>
> I had a look at IEP and have several comments:
>
> 1. Why would one want to use to use server's default values for Concurrency
> or Isolation?
> I believe, client should have its own defaults which should be explicitly
> documented, so that
> behaviour of transactions will not depend on the server node it was routed
> to. The same goes
> for timeout.
>
> 2. Not sure about transaction ID represented by int. Why not to use
> IgniteUuid? It should simplify
> server code. Also it may help with monitoring/debugging if thin clients and
> server nodes use the
> same identifier for transactions. It does not seem as a big overhead to me
> either.
>
> 3. Maybe it makes sense to add "In transaction" boolean flag to cache
> operation request header
> to avoid bloating message size in non-affected scenarios.
>
> Best Regards,
> Igor
>
>
> On Mon, May 13, 2019 at 1:58 PM Alex Plehanov 
> wrote:
>
> > Hi, Ivan.
> >
> > Thanks for your comments.
> >
> > 1. Transaction id in thin client protocol it's just a tx counter for the
> > current connection. It's not related to GridCacheVersion. If we want to
> > know GridCacheVersion on the client side, I think we should introduce a
> new
> > type of operation (for example OP_TX_INFO).
> > 2. Error handling is already provided by thin client protocol, even in
> case
> > of empty response. Of course, the client will know if there is a failure
> > occurred during OP_TX_END operation.
> > 3. AFAIK some of thin client implementations already send requests and
> > process responses in an async way (.NET for example). As for java thin
> > client, in the current implementation channel is locked exclusively
> before
> > request send and until the response is processed. I have some ideas about
> > how to fix this (split send/receive process into two different parts and
> > acquire locks for this parts separately or create futures on request sent
> > and complete it after processing the response in a dedicated thread),
> I've
> > created ticket [1] for this issue and will try to implement prototype in
> a
> > couple of days.
> >
> > About suspend/resume, yes, on server-side we should resume tx before each
> > transactional cache operation and suspend the tx after the operation. In
> my
> > opinion, suspend/resume approach have several advantages over approach
> with
> > explicit tx id argument:
> > - Introducing explicit tx id argument for cache operations leads to a
> > significant API change
> > - It's not clear how to use it together with current (tx-per-thread)
> > approach (for example, what if a thread is already held transaction and
> > someone call cache operation with explicit tx id?)
> > - Suspend/resume feature will also be useful for thick clients
> > - Suspend/resume functionality is already partially implemented (for
> > optimistic transactions only)
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> >
> > пт, 3 мая 2019 г. в 08:10, Павлухин Иван :
> >
> > > Hi Alex,
> > >
> > > I went through IEP [1] and I have a couple of questions:
> > > 1. What is going to be used as transaction id? In a described protocol
> > > I see an int field for it. Should not it be GridCacheVersion
> > > corresponding to IgniteInternalTx#xidVersion?
> > > 2. OP_TX_END message assumes an empty response, but I think that
> > > errors during tx finish are possible and should be returned in a
> > > response.
> > > 3. In IEP it is stated that async processing of lock operations should
> > > be introduced on a client side to enable concurrent operations from
> > > different client threads. Do you have an idea how to achieve it?
> > >
> > > Also, a bit about a 

Re: Thin client: transactions support

[Igor Sapego]

Hi,

I had a look at IEP and have several comments:

1. Why would one want to use to use server's default values for Concurrency
or Isolation?
I believe, client should have its own defaults which should be explicitly
documented, so that
behaviour of transactions will not depend on the server node it was routed
to. The same goes
for timeout.

2. Not sure about transaction ID represented by int. Why not to use
IgniteUuid? It should simplify
server code. Also it may help with monitoring/debugging if thin clients and
server nodes use the
same identifier for transactions. It does not seem as a big overhead to me
either.

3. Maybe it makes sense to add "In transaction" boolean flag to cache
operation request header
to avoid bloating message size in non-affected scenarios.

Best Regards,
Igor


On Mon, May 13, 2019 at 1:58 PM Alex Plehanov 
wrote:

> Hi, Ivan.
>
> Thanks for your comments.
>
> 1. Transaction id in thin client protocol it's just a tx counter for the
> current connection. It's not related to GridCacheVersion. If we want to
> know GridCacheVersion on the client side, I think we should introduce a new
> type of operation (for example OP_TX_INFO).
> 2. Error handling is already provided by thin client protocol, even in case
> of empty response. Of course, the client will know if there is a failure
> occurred during OP_TX_END operation.
> 3. AFAIK some of thin client implementations already send requests and
> process responses in an async way (.NET for example). As for java thin
> client, in the current implementation channel is locked exclusively before
> request send and until the response is processed. I have some ideas about
> how to fix this (split send/receive process into two different parts and
> acquire locks for this parts separately or create futures on request sent
> and complete it after processing the response in a dedicated thread), I've
> created ticket [1] for this issue and will try to implement prototype in a
> couple of days.
>
> About suspend/resume, yes, on server-side we should resume tx before each
> transactional cache operation and suspend the tx after the operation. In my
> opinion, suspend/resume approach have several advantages over approach with
> explicit tx id argument:
> - Introducing explicit tx id argument for cache operations leads to a
> significant API change
> - It's not clear how to use it together with current (tx-per-thread)
> approach (for example, what if a thread is already held transaction and
> someone call cache operation with explicit tx id?)
> - Suspend/resume feature will also be useful for thick clients
> - Suspend/resume functionality is already partially implemented (for
> optimistic transactions only)
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11685
>
> пт, 3 мая 2019 г. в 08:10, Павлухин Иван :
>
> > Hi Alex,
> >
> > I went through IEP [1] and I have a couple of questions:
> > 1. What is going to be used as transaction id? In a described protocol
> > I see an int field for it. Should not it be GridCacheVersion
> > corresponding to IgniteInternalTx#xidVersion?
> > 2. OP_TX_END message assumes an empty response, but I think that
> > errors during tx finish are possible and should be returned in a
> > response.
> > 3. In IEP it is stated that async processing of lock operations should
> > be introduced on a client side to enable concurrent operations from
> > different client threads. Do you have an idea how to achieve it?
> >
> > Also, a bit about a suspend/resume trait. I tried to think about it
> > leaving away an existing transactions implementation in Ignite. As I
> > understood we are going to resume a tx before each cache operation in
> > the tx and resume the tx after the operation. All this to make an
> > executing thread available for other operations (e.g. in other txs).
> > From the first glance it seems like an inversed logic. A
> > straightforward way is to execute a cache operation within a
> > particular transaction defined as an explicit tx id argument (e.g.
> > cache.put(key, value, txid)). Can we do so?
> >
> > And leaving for now thin client API. I cannot say that one proposed in
> > IEP is good or bad. I can only say that it ressembles current thick
> > client API. And perhaps it should not. I think that we should consider
> > similar APIs provided by other vendors and keep in mind that we have a
> > bunch of client implementations for different languages. I suppose
> > that we can return to it a little bit later. And I hope that we will
> > do it.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> > вт, 30 апр. 2019 г. в 13:24, Alex Plehanov :
> > >
> > > Hello, Igniters!
> > >
> > > I've update IEP [1] and implement PoC according to new approach
> (multiple
> > > concurrent transactions per connection).
> > > But to move forward another feature need to be implemented:
> > suspend/resume
> > > for pessimistic transactions (IGNITE-5714 [2]). 

Re: Thin client: transactions support

[Alex Plehanov]

Hi, Ivan.

Thanks for your comments.

1. Transaction id in thin client protocol it's just a tx counter for the
current connection. It's not related to GridCacheVersion. If we want to
know GridCacheVersion on the client side, I think we should introduce a new
type of operation (for example OP_TX_INFO).
2. Error handling is already provided by thin client protocol, even in case
of empty response. Of course, the client will know if there is a failure
occurred during OP_TX_END operation.
3. AFAIK some of thin client implementations already send requests and
process responses in an async way (.NET for example). As for java thin
client, in the current implementation channel is locked exclusively before
request send and until the response is processed. I have some ideas about
how to fix this (split send/receive process into two different parts and
acquire locks for this parts separately or create futures on request sent
and complete it after processing the response in a dedicated thread), I've
created ticket [1] for this issue and will try to implement prototype in a
couple of days.

About suspend/resume, yes, on server-side we should resume tx before each
transactional cache operation and suspend the tx after the operation. In my
opinion, suspend/resume approach have several advantages over approach with
explicit tx id argument:
- Introducing explicit tx id argument for cache operations leads to a
significant API change
- It's not clear how to use it together with current (tx-per-thread)
approach (for example, what if a thread is already held transaction and
someone call cache operation with explicit tx id?)
- Suspend/resume feature will also be useful for thick clients
- Suspend/resume functionality is already partially implemented (for
optimistic transactions only)

[1] https://issues.apache.org/jira/browse/IGNITE-11685

пт, 3 мая 2019 г. в 08:10, Павлухин Иван :

> Hi Alex,
>
> I went through IEP [1] and I have a couple of questions:
> 1. What is going to be used as transaction id? In a described protocol
> I see an int field for it. Should not it be GridCacheVersion
> corresponding to IgniteInternalTx#xidVersion?
> 2. OP_TX_END message assumes an empty response, but I think that
> errors during tx finish are possible and should be returned in a
> response.
> 3. In IEP it is stated that async processing of lock operations should
> be introduced on a client side to enable concurrent operations from
> different client threads. Do you have an idea how to achieve it?
>
> Also, a bit about a suspend/resume trait. I tried to think about it
> leaving away an existing transactions implementation in Ignite. As I
> understood we are going to resume a tx before each cache operation in
> the tx and resume the tx after the operation. All this to make an
> executing thread available for other operations (e.g. in other txs).
> From the first glance it seems like an inversed logic. A
> straightforward way is to execute a cache operation within a
> particular transaction defined as an explicit tx id argument (e.g.
> cache.put(key, value, txid)). Can we do so?
>
> And leaving for now thin client API. I cannot say that one proposed in
> IEP is good or bad. I can only say that it ressembles current thick
> client API. And perhaps it should not. I think that we should consider
> similar APIs provided by other vendors and keep in mind that we have a
> bunch of client implementations for different languages. I suppose
> that we can return to it a little bit later. And I hope that we will
> do it.
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
> вт, 30 апр. 2019 г. в 13:24, Alex Plehanov :
> >
> > Hello, Igniters!
> >
> > I've update IEP [1] and implement PoC according to new approach (multiple
> > concurrent transactions per connection).
> > But to move forward another feature need to be implemented:
> suspend/resume
> > for pessimistic transactions (IGNITE-5714 [2]). Implementation of
> > suspend/resume is ready now and ticket in 'Patch available' status. Can
> any
> > transactions expert help with review of IGNITE-5714?
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > [2]: https://issues.apache.org/jira/browse/IGNITE-5714
> >
> > чт, 4 апр. 2019 г. в 11:32, Alex Plehanov :
> >
> > > Vladimir,
> > >
> > > Ok, then I will rewrite IEP in the near future.
> > >
> > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov :
> > >
> > >> Hi Alex,
> > >>
> > >> I think we should be able to handle many transactions through a single
> > >> connection. This will make our protocol and client implementations
> much
> > >> more efficient, and simplicity from developer's perspective is not our
> > >> goal. Consider normal nodes. We have server nodes and client nodes.
> You
> > >> may
> > >> span whatever number of transactions you need, but all of them are
> > >> coordinated through a single connection. The same should be
> 

Re: Thin client: transactions support

[Павлухин Иван]

Hi Alex,

I went through IEP [1] and I have a couple of questions:
1. What is going to be used as transaction id? In a described protocol
I see an int field for it. Should not it be GridCacheVersion
corresponding to IgniteInternalTx#xidVersion?
2. OP_TX_END message assumes an empty response, but I think that
errors during tx finish are possible and should be returned in a
response.
3. In IEP it is stated that async processing of lock operations should
be introduced on a client side to enable concurrent operations from
different client threads. Do you have an idea how to achieve it?

Also, a bit about a suspend/resume trait. I tried to think about it
leaving away an existing transactions implementation in Ignite. As I
understood we are going to resume a tx before each cache operation in
the tx and resume the tx after the operation. All this to make an
executing thread available for other operations (e.g. in other txs).
>From the first glance it seems like an inversed logic. A
straightforward way is to execute a cache operation within a
particular transaction defined as an explicit tx id argument (e.g.
cache.put(key, value, txid)). Can we do so?

And leaving for now thin client API. I cannot say that one proposed in
IEP is good or bad. I can only say that it ressembles current thick
client API. And perhaps it should not. I think that we should consider
similar APIs provided by other vendors and keep in mind that we have a
bunch of client implementations for different languages. I suppose
that we can return to it a little bit later. And I hope that we will
do it.

[1] 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support

вт, 30 апр. 2019 г. в 13:24, Alex Plehanov :
>
> Hello, Igniters!
>
> I've update IEP [1] and implement PoC according to new approach (multiple
> concurrent transactions per connection).
> But to move forward another feature need to be implemented: suspend/resume
> for pessimistic transactions (IGNITE-5714 [2]). Implementation of
> suspend/resume is ready now and ticket in 'Patch available' status. Can any
> transactions expert help with review of IGNITE-5714?
>
> [1]:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> [2]: https://issues.apache.org/jira/browse/IGNITE-5714
>
> чт, 4 апр. 2019 г. в 11:32, Alex Plehanov :
>
> > Vladimir,
> >
> > Ok, then I will rewrite IEP in the near future.
> >
> > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov :
> >
> >> Hi Alex,
> >>
> >> I think we should be able to handle many transactions through a single
> >> connection. This will make our protocol and client implementations much
> >> more efficient, and simplicity from developer's perspective is not our
> >> goal. Consider normal nodes. We have server nodes and client nodes. You
> >> may
> >> span whatever number of transactions you need, but all of them are
> >> coordinated through a single connection. The same should be applicable to
> >> thin clients. Protocol is already designed to handle this, as we pass
> >> unique operation ID in order to distinguish one operation from another. It
> >> is true, though, that we will have to introduce a kind of "session"
> >> concept, and pass additional identifier along with cache operations, but
> >> this doesn't sound like a problem to me.
> >>
> >> And provided that currently server-side transactions are bound to threads
> >> artificially, I would say that the first step in implementation of
> >> transactions on thin clients should be decoupling server-side transactions
> >> from threads. Without this we will have very inefficient implementation,
> >> when every new client transaction have to spawn a new thread. This is slow
> >> and introduces high memory pressure on a cluster node. We already work
> >> this
> >> way for MVCC transactions which are spawned from JDBC driver, and believe
> >> me, we do not want to replicated this bad practice to other clients :-)
> >>
> >> Vladimir.
> >>
> >> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov 
> >> wrote:
> >>
> >> > Guys, so, do we need multiple concurrent transactions per connection?
> >> >
> >> > There are pros and cons for each approach. Difference between
> >> approaches:
> >> >
> >> > One transaction at a time per connection:
> >> >  - This approach is used in RDBMS world and users got used to it
> >> >  - To use transactions concurrently users need to use different
> >> connections
> >> > and get these connections via something like a connection pool
> >> >  - Easy to implement (in fact, PoC is already done)
> >> >
> >> > Multiple concurrent transactions per connection:
> >> >  - At least for java thin client, we can implement transaction per
> >> thread
> >> > approach as implemented now for the thick client (perhaps other thin
> >> > clients can implement the same abstraction)
> >> >  - There is also protocol change for all cache operations needed (to
> >> bind
> >> > cache operation to the transaction)
> >> >  - 

Re: Thin client: transactions support

[Alex Plehanov]

Hello, Igniters!

I've update IEP [1] and implement PoC according to new approach (multiple
concurrent transactions per connection).
But to move forward another feature need to be implemented: suspend/resume
for pessimistic transactions (IGNITE-5714 [2]). Implementation of
suspend/resume is ready now and ticket in 'Patch available' status. Can any
transactions expert help with review of IGNITE-5714?

[1]:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
[2]: https://issues.apache.org/jira/browse/IGNITE-5714

чт, 4 апр. 2019 г. в 11:32, Alex Plehanov :

> Vladimir,
>
> Ok, then I will rewrite IEP in the near future.
>
> чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov :
>
>> Hi Alex,
>>
>> I think we should be able to handle many transactions through a single
>> connection. This will make our protocol and client implementations much
>> more efficient, and simplicity from developer's perspective is not our
>> goal. Consider normal nodes. We have server nodes and client nodes. You
>> may
>> span whatever number of transactions you need, but all of them are
>> coordinated through a single connection. The same should be applicable to
>> thin clients. Protocol is already designed to handle this, as we pass
>> unique operation ID in order to distinguish one operation from another. It
>> is true, though, that we will have to introduce a kind of "session"
>> concept, and pass additional identifier along with cache operations, but
>> this doesn't sound like a problem to me.
>>
>> And provided that currently server-side transactions are bound to threads
>> artificially, I would say that the first step in implementation of
>> transactions on thin clients should be decoupling server-side transactions
>> from threads. Without this we will have very inefficient implementation,
>> when every new client transaction have to spawn a new thread. This is slow
>> and introduces high memory pressure on a cluster node. We already work
>> this
>> way for MVCC transactions which are spawned from JDBC driver, and believe
>> me, we do not want to replicated this bad practice to other clients :-)
>>
>> Vladimir.
>>
>> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov 
>> wrote:
>>
>> > Guys, so, do we need multiple concurrent transactions per connection?
>> >
>> > There are pros and cons for each approach. Difference between
>> approaches:
>> >
>> > One transaction at a time per connection:
>> >  - This approach is used in RDBMS world and users got used to it
>> >  - To use transactions concurrently users need to use different
>> connections
>> > and get these connections via something like a connection pool
>> >  - Easy to implement (in fact, PoC is already done)
>> >
>> > Multiple concurrent transactions per connection:
>> >  - At least for java thin client, we can implement transaction per
>> thread
>> > approach as implemented now for the thick client (perhaps other thin
>> > clients can implement the same abstraction)
>> >  - There is also protocol change for all cache operations needed (to
>> bind
>> > cache operation to the transaction)
>> >  - Significant changes to all implemented clients are needed
>> >  - Implementation on the server side is more complex
>> >
>> > What do you think?
>> >
>> >
>> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov :
>> >
>> > > Ilya,
>> > >
>> > > > We should be able to multiplex several transactions using a single
>> > > Client connection.
>> > > In this case, we should significantly change cache operations syntax
>> (for
>> > > each implemented client), to bind each operation to the transaction.
>> > >
>> > > > I want to also ask if "Number of entries participating in
>> transaction
>> > > (may be approximate). 0 - default value." is needed.
>> > > I've tried to minimize API changes between thick and thin client to
>> > > simplify move from one to another. It's the only reason. But I agree
>> with
>> > > you, the parameter is not very useful.
>> > >
>> > >
>> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com>:
>> > >
>> > >> Hello!
>> > >>
>> > >> Pavel, I agree with you thorougly. We should be able to multiplex
>> > several
>> > >> transactions using a single Client connection. This means adding
>> > >> Transaction id parameter to every affected cache operation / SQL
>> > statement
>> > >> (if applicable) to make sure we do cache operations on relevant
>> > >> transaction.
>> > >>
>> > >> This is how other things work in Ignite, such as communication. We do
>> > not
>> > >> open dozens of connections, we multiplex operations asynchronously
>> > through
>> > >> a single connection.
>> > >>
>> > >> I think that trying to pool Ignite connections will be highly
>> > >> inconvenient,
>> > >> since there is no existing infrastructure for such pooling (like
>> there
>> > >> exists for JDBC).
>> > >>
>> > >> I want to also ask if "Number of entries participating in transaction
>> > (may
>> > >> be approximate). 0 - default value." is 

Re: Thin client: transactions support

[Alex Plehanov]

Vladimir,

Ok, then I will rewrite IEP in the near future.

чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov :

> Hi Alex,
>
> I think we should be able to handle many transactions through a single
> connection. This will make our protocol and client implementations much
> more efficient, and simplicity from developer's perspective is not our
> goal. Consider normal nodes. We have server nodes and client nodes. You may
> span whatever number of transactions you need, but all of them are
> coordinated through a single connection. The same should be applicable to
> thin clients. Protocol is already designed to handle this, as we pass
> unique operation ID in order to distinguish one operation from another. It
> is true, though, that we will have to introduce a kind of "session"
> concept, and pass additional identifier along with cache operations, but
> this doesn't sound like a problem to me.
>
> And provided that currently server-side transactions are bound to threads
> artificially, I would say that the first step in implementation of
> transactions on thin clients should be decoupling server-side transactions
> from threads. Without this we will have very inefficient implementation,
> when every new client transaction have to spawn a new thread. This is slow
> and introduces high memory pressure on a cluster node. We already work this
> way for MVCC transactions which are spawned from JDBC driver, and believe
> me, we do not want to replicated this bad practice to other clients :-)
>
> Vladimir.
>
> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov 
> wrote:
>
> > Guys, so, do we need multiple concurrent transactions per connection?
> >
> > There are pros and cons for each approach. Difference between approaches:
> >
> > One transaction at a time per connection:
> >  - This approach is used in RDBMS world and users got used to it
> >  - To use transactions concurrently users need to use different
> connections
> > and get these connections via something like a connection pool
> >  - Easy to implement (in fact, PoC is already done)
> >
> > Multiple concurrent transactions per connection:
> >  - At least for java thin client, we can implement transaction per thread
> > approach as implemented now for the thick client (perhaps other thin
> > clients can implement the same abstraction)
> >  - There is also protocol change for all cache operations needed (to bind
> > cache operation to the transaction)
> >  - Significant changes to all implemented clients are needed
> >  - Implementation on the server side is more complex
> >
> > What do you think?
> >
> >
> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov :
> >
> > > Ilya,
> > >
> > > > We should be able to multiplex several transactions using a single
> > > Client connection.
> > > In this case, we should significantly change cache operations syntax
> (for
> > > each implemented client), to bind each operation to the transaction.
> > >
> > > > I want to also ask if "Number of entries participating in transaction
> > > (may be approximate). 0 - default value." is needed.
> > > I've tried to minimize API changes between thick and thin client to
> > > simplify move from one to another. It's the only reason. But I agree
> with
> > > you, the parameter is not very useful.
> > >
> > >
> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev  >:
> > >
> > >> Hello!
> > >>
> > >> Pavel, I agree with you thorougly. We should be able to multiplex
> > several
> > >> transactions using a single Client connection. This means adding
> > >> Transaction id parameter to every affected cache operation / SQL
> > statement
> > >> (if applicable) to make sure we do cache operations on relevant
> > >> transaction.
> > >>
> > >> This is how other things work in Ignite, such as communication. We do
> > not
> > >> open dozens of connections, we multiplex operations asynchronously
> > through
> > >> a single connection.
> > >>
> > >> I think that trying to pool Ignite connections will be highly
> > >> inconvenient,
> > >> since there is no existing infrastructure for such pooling (like there
> > >> exists for JDBC).
> > >>
> > >> I want to also ask if "Number of entries participating in transaction
> > (may
> > >> be approximate). 0 - default value." is needed. Does it actually do
> > >> anything in our tx protocol? Users of existing APIs are already
> confused
> > >> by
> > >> this parameter, if we could get rid of it in thin client protocol it
> > would
> > >> be nice clean-up.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn :
> > >>
> > >> > Alex,
> > >> >
> > >> > > now we can only support one active transaction per connection
> > >> >
> > >> > I totally understand server-side and protocol limitations that are
> > >> causing
> > >> > this.
> > >> > But I have no idea how to support this in .NET Thin Client, for
> > example.
> > >> >
> > >> > It is thread-safe and can handle multiple async operations in
> > parallel.
> > >> > 

Re: Thin client: transactions support

[Vladimir Ozerov]

Hi Alex,

I think we should be able to handle many transactions through a single
connection. This will make our protocol and client implementations much
more efficient, and simplicity from developer's perspective is not our
goal. Consider normal nodes. We have server nodes and client nodes. You may
span whatever number of transactions you need, but all of them are
coordinated through a single connection. The same should be applicable to
thin clients. Protocol is already designed to handle this, as we pass
unique operation ID in order to distinguish one operation from another. It
is true, though, that we will have to introduce a kind of "session"
concept, and pass additional identifier along with cache operations, but
this doesn't sound like a problem to me.

And provided that currently server-side transactions are bound to threads
artificially, I would say that the first step in implementation of
transactions on thin clients should be decoupling server-side transactions
from threads. Without this we will have very inefficient implementation,
when every new client transaction have to spawn a new thread. This is slow
and introduces high memory pressure on a cluster node. We already work this
way for MVCC transactions which are spawned from JDBC driver, and believe
me, we do not want to replicated this bad practice to other clients :-)

Vladimir.

On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov 
wrote:

> Guys, so, do we need multiple concurrent transactions per connection?
>
> There are pros and cons for each approach. Difference between approaches:
>
> One transaction at a time per connection:
>  - This approach is used in RDBMS world and users got used to it
>  - To use transactions concurrently users need to use different connections
> and get these connections via something like a connection pool
>  - Easy to implement (in fact, PoC is already done)
>
> Multiple concurrent transactions per connection:
>  - At least for java thin client, we can implement transaction per thread
> approach as implemented now for the thick client (perhaps other thin
> clients can implement the same abstraction)
>  - There is also protocol change for all cache operations needed (to bind
> cache operation to the transaction)
>  - Significant changes to all implemented clients are needed
>  - Implementation on the server side is more complex
>
> What do you think?
>
>
> вт, 2 апр. 2019 г. в 16:29, Alex Plehanov :
>
> > Ilya,
> >
> > > We should be able to multiplex several transactions using a single
> > Client connection.
> > In this case, we should significantly change cache operations syntax (for
> > each implemented client), to bind each operation to the transaction.
> >
> > > I want to also ask if "Number of entries participating in transaction
> > (may be approximate). 0 - default value." is needed.
> > I've tried to minimize API changes between thick and thin client to
> > simplify move from one to another. It's the only reason. But I agree with
> > you, the parameter is not very useful.
> >
> >
> > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev :
> >
> >> Hello!
> >>
> >> Pavel, I agree with you thorougly. We should be able to multiplex
> several
> >> transactions using a single Client connection. This means adding
> >> Transaction id parameter to every affected cache operation / SQL
> statement
> >> (if applicable) to make sure we do cache operations on relevant
> >> transaction.
> >>
> >> This is how other things work in Ignite, such as communication. We do
> not
> >> open dozens of connections, we multiplex operations asynchronously
> through
> >> a single connection.
> >>
> >> I think that trying to pool Ignite connections will be highly
> >> inconvenient,
> >> since there is no existing infrastructure for such pooling (like there
> >> exists for JDBC).
> >>
> >> I want to also ask if "Number of entries participating in transaction
> (may
> >> be approximate). 0 - default value." is needed. Does it actually do
> >> anything in our tx protocol? Users of existing APIs are already confused
> >> by
> >> this parameter, if we could get rid of it in thin client protocol it
> would
> >> be nice clean-up.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn :
> >>
> >> > Alex,
> >> >
> >> > > now we can only support one active transaction per connection
> >> >
> >> > I totally understand server-side and protocol limitations that are
> >> causing
> >> > this.
> >> > But I have no idea how to support this in .NET Thin Client, for
> example.
> >> >
> >> > It is thread-safe and can handle multiple async operations in
> parallel.
> >> > But with TX support we have to somehow switch to single-threaded mode
> to
> >> > avoid unexpected effects.
> >> >
> >> > Any ideas?
> >> >
> >> >
> >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov  >
> >> > wrote:
> >> >
> >> > > Dmitriy, thank you!
> >> > >
> >> > > Guys, I've created the IEP [1] on wiki, please have a look.
> >> > >
> >> > > 

Re: Thin client: transactions support

[Alex Plehanov]

Guys, so, do we need multiple concurrent transactions per connection?

There are pros and cons for each approach. Difference between approaches:

One transaction at a time per connection:
 - This approach is used in RDBMS world and users got used to it
 - To use transactions concurrently users need to use different connections
and get these connections via something like a connection pool
 - Easy to implement (in fact, PoC is already done)

Multiple concurrent transactions per connection:
 - At least for java thin client, we can implement transaction per thread
approach as implemented now for the thick client (perhaps other thin
clients can implement the same abstraction)
 - There is also protocol change for all cache operations needed (to bind
cache operation to the transaction)
 - Significant changes to all implemented clients are needed
 - Implementation on the server side is more complex

What do you think?


вт, 2 апр. 2019 г. в 16:29, Alex Plehanov :

> Ilya,
>
> > We should be able to multiplex several transactions using a single
> Client connection.
> In this case, we should significantly change cache operations syntax (for
> each implemented client), to bind each operation to the transaction.
>
> > I want to also ask if "Number of entries participating in transaction
> (may be approximate). 0 - default value." is needed.
> I've tried to minimize API changes between thick and thin client to
> simplify move from one to another. It's the only reason. But I agree with
> you, the parameter is not very useful.
>
>
> вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev :
>
>> Hello!
>>
>> Pavel, I agree with you thorougly. We should be able to multiplex several
>> transactions using a single Client connection. This means adding
>> Transaction id parameter to every affected cache operation / SQL statement
>> (if applicable) to make sure we do cache operations on relevant
>> transaction.
>>
>> This is how other things work in Ignite, such as communication. We do not
>> open dozens of connections, we multiplex operations asynchronously through
>> a single connection.
>>
>> I think that trying to pool Ignite connections will be highly
>> inconvenient,
>> since there is no existing infrastructure for such pooling (like there
>> exists for JDBC).
>>
>> I want to also ask if "Number of entries participating in transaction (may
>> be approximate). 0 - default value." is needed. Does it actually do
>> anything in our tx protocol? Users of existing APIs are already confused
>> by
>> this parameter, if we could get rid of it in thin client protocol it would
>> be nice clean-up.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn :
>>
>> > Alex,
>> >
>> > > now we can only support one active transaction per connection
>> >
>> > I totally understand server-side and protocol limitations that are
>> causing
>> > this.
>> > But I have no idea how to support this in .NET Thin Client, for example.
>> >
>> > It is thread-safe and can handle multiple async operations in parallel.
>> > But with TX support we have to somehow switch to single-threaded mode to
>> > avoid unexpected effects.
>> >
>> > Any ideas?
>> >
>> >
>> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov 
>> > wrote:
>> >
>> > > Dmitriy, thank you!
>> > >
>> > > Guys, I've created the IEP [1] on wiki, please have a look.
>> > >
>> > > [1]
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > >
>> > >
>> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov :
>> > >
>> > > > Hi,
>> > > >
>> > > > I've added permissions to account plehanov.alex
>> > > >
>> > > > Recently Infra integrated Apache LDAP with confluence, so it is
>> > possible
>> > > to
>> > > > login using Apache credentials. Probably we can ask infra if extra
>> > > > permissions to edit pages should be added for committers.
>> > > >
>> > > > Sincerely,
>> > > > Dmitriy Pavlov
>> > > >
>> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov > >:
>> > > >
>> > > > > Vladimir,
>> > > > >
>> > > > > About current tx: ok, then we don't need tx() method in the
>> interface
>> > > at
>> > > > > all (the same cached transaction info user can store by himself).
>> > > > >
>> > > > > About decoupling transactions from threads on the server side: for
>> > now,
>> > > > we
>> > > > > can start with thread-per-connection approach (we only can support
>> > one
>> > > > > active transaction per connection, see below, so we need one
>> > additional
>> > > > > dedicated thread for each connection with active transaction), and
>> > > later
>> > > > > change server-side internals to process client transactions in any
>> > > server
>> > > > > thread (not dedicated to this connection). This change will not
>> > affect
>> > > > the
>> > > > > thin client protocol, it only affects the server side.
>> > > > > In any case, we can't support concurrent transactions per
>> connection
>> > on
>> > > > > the client side without fundamental 

Re: Thin client: transactions support

[Alex Plehanov]

Ilya,

> We should be able to multiplex several transactions using a single Client
connection.
In this case, we should significantly change cache operations syntax (for
each implemented client), to bind each operation to the transaction.

> I want to also ask if "Number of entries participating in transaction
(may be approximate). 0 - default value." is needed.
I've tried to minimize API changes between thick and thin client to
simplify move from one to another. It's the only reason. But I agree with
you, the parameter is not very useful.


вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev :

> Hello!
>
> Pavel, I agree with you thorougly. We should be able to multiplex several
> transactions using a single Client connection. This means adding
> Transaction id parameter to every affected cache operation / SQL statement
> (if applicable) to make sure we do cache operations on relevant
> transaction.
>
> This is how other things work in Ignite, such as communication. We do not
> open dozens of connections, we multiplex operations asynchronously through
> a single connection.
>
> I think that trying to pool Ignite connections will be highly inconvenient,
> since there is no existing infrastructure for such pooling (like there
> exists for JDBC).
>
> I want to also ask if "Number of entries participating in transaction (may
> be approximate). 0 - default value." is needed. Does it actually do
> anything in our tx protocol? Users of existing APIs are already confused by
> this parameter, if we could get rid of it in thin client protocol it would
> be nice clean-up.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn :
>
> > Alex,
> >
> > > now we can only support one active transaction per connection
> >
> > I totally understand server-side and protocol limitations that are
> causing
> > this.
> > But I have no idea how to support this in .NET Thin Client, for example.
> >
> > It is thread-safe and can handle multiple async operations in parallel.
> > But with TX support we have to somehow switch to single-threaded mode to
> > avoid unexpected effects.
> >
> > Any ideas?
> >
> >
> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov 
> > wrote:
> >
> > > Dmitriy, thank you!
> > >
> > > Guys, I've created the IEP [1] on wiki, please have a look.
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >
> > >
> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov :
> > >
> > > > Hi,
> > > >
> > > > I've added permissions to account plehanov.alex
> > > >
> > > > Recently Infra integrated Apache LDAP with confluence, so it is
> > possible
> > > to
> > > > login using Apache credentials. Probably we can ask infra if extra
> > > > permissions to edit pages should be added for committers.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov  >:
> > > >
> > > > > Vladimir,
> > > > >
> > > > > About current tx: ok, then we don't need tx() method in the
> interface
> > > at
> > > > > all (the same cached transaction info user can store by himself).
> > > > >
> > > > > About decoupling transactions from threads on the server side: for
> > now,
> > > > we
> > > > > can start with thread-per-connection approach (we only can support
> > one
> > > > > active transaction per connection, see below, so we need one
> > additional
> > > > > dedicated thread for each connection with active transaction), and
> > > later
> > > > > change server-side internals to process client transactions in any
> > > server
> > > > > thread (not dedicated to this connection). This change will not
> > affect
> > > > the
> > > > > thin client protocol, it only affects the server side.
> > > > > In any case, we can't support concurrent transactions per
> connection
> > on
> > > > > the client side without fundamental changes to the current protocol
> > > > (cache
> > > > > operation doesn't bound to transaction or thread and the server
> > doesn't
> > > > > know which thread on the client side do this cache operation). In
> my
> > > > > opinion, if a user wants to use concurrent transactions, he must
> use
> > > > > different connections from a connection pool.
> > > > >
> > > > > About semantics of suspend/resume on the client-side: it's
> absolutely
> > > > > different than server-side semantics (we don't need to do
> > > suspend/resume
> > > > to
> > > > > pass transaction between threads on the client-side), but can't be
> > > > > implemented efficiently without implemented suspend/resume on
> > > > server-side.
> > > > >
> > > > > Can anyone give me permissions to create IEP on Apache wiki?
> > > > >
> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov  >:
> > > > >
> > > > > > Hi Alex,
> > > > > >
> > > > > > My comments was only about the protocol. Getting current info
> about
> > > > > > transaction should be handled by the client itself. It is not
> > > protocl's
> > > > > > concern. Same about 

Re: Thin client: transactions support

[Ilya Kasnacheev]

Hello!

Pavel, I agree with you thorougly. We should be able to multiplex several
transactions using a single Client connection. This means adding
Transaction id parameter to every affected cache operation / SQL statement
(if applicable) to make sure we do cache operations on relevant transaction.

This is how other things work in Ignite, such as communication. We do not
open dozens of connections, we multiplex operations asynchronously through
a single connection.

I think that trying to pool Ignite connections will be highly inconvenient,
since there is no existing infrastructure for such pooling (like there
exists for JDBC).

I want to also ask if "Number of entries participating in transaction (may
be approximate). 0 - default value." is needed. Does it actually do
anything in our tx protocol? Users of existing APIs are already confused by
this parameter, if we could get rid of it in thin client protocol it would
be nice clean-up.

Regards,
-- 
Ilya Kasnacheev


вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn :

> Alex,
>
> > now we can only support one active transaction per connection
>
> I totally understand server-side and protocol limitations that are causing
> this.
> But I have no idea how to support this in .NET Thin Client, for example.
>
> It is thread-safe and can handle multiple async operations in parallel.
> But with TX support we have to somehow switch to single-threaded mode to
> avoid unexpected effects.
>
> Any ideas?
>
>
> On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov 
> wrote:
>
> > Dmitriy, thank you!
> >
> > Guys, I've created the IEP [1] on wiki, please have a look.
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> >
> > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov :
> >
> > > Hi,
> > >
> > > I've added permissions to account plehanov.alex
> > >
> > > Recently Infra integrated Apache LDAP with confluence, so it is
> possible
> > to
> > > login using Apache credentials. Probably we can ask infra if extra
> > > permissions to edit pages should be added for committers.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov :
> > >
> > > > Vladimir,
> > > >
> > > > About current tx: ok, then we don't need tx() method in the interface
> > at
> > > > all (the same cached transaction info user can store by himself).
> > > >
> > > > About decoupling transactions from threads on the server side: for
> now,
> > > we
> > > > can start with thread-per-connection approach (we only can support
> one
> > > > active transaction per connection, see below, so we need one
> additional
> > > > dedicated thread for each connection with active transaction), and
> > later
> > > > change server-side internals to process client transactions in any
> > server
> > > > thread (not dedicated to this connection). This change will not
> affect
> > > the
> > > > thin client protocol, it only affects the server side.
> > > > In any case, we can't support concurrent transactions per connection
> on
> > > > the client side without fundamental changes to the current protocol
> > > (cache
> > > > operation doesn't bound to transaction or thread and the server
> doesn't
> > > > know which thread on the client side do this cache operation). In my
> > > > opinion, if a user wants to use concurrent transactions, he must use
> > > > different connections from a connection pool.
> > > >
> > > > About semantics of suspend/resume on the client-side: it's absolutely
> > > > different than server-side semantics (we don't need to do
> > suspend/resume
> > > to
> > > > pass transaction between threads on the client-side), but can't be
> > > > implemented efficiently without implemented suspend/resume on
> > > server-side.
> > > >
> > > > Can anyone give me permissions to create IEP on Apache wiki?
> > > >
> > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov :
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > My comments was only about the protocol. Getting current info about
> > > > > transaction should be handled by the client itself. It is not
> > protocl's
> > > > > concern. Same about other APIs and behavior in case another
> > transaction
> > > > is
> > > > > attempted from the same thread.
> > > > >
> > > > > Putting protocol aside, transaction support is complicated matter.
> I
> > > > would
> > > > > propose to route through IEP and wide community discussion. We need
> > to
> > > > > review API and semantics very carefully, taking SUSPEND/RESUME in
> > > count.
> > > > > Also I do not see how we support client transactions efficiently
> > > without
> > > > > decoupling transactions from threads on the server side first.
> > Because
> > > > > without it you will need a dedicated server thread for every
> client's
> > > > > transaction which is slow and may even crash the server.
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > > plehanov.a...@gmail.com>
> > > > > 

Re: Thin client: transactions support

[Alex Plehanov]

Pavel,

AFAIK usually, such limitations handled by using connection pools. If a
thread needs to start a transaction, it acquires a connection from the pool
and releases the connection after the transaction end.

вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn :

> Alex,
>
> > now we can only support one active transaction per connection
>
> I totally understand server-side and protocol limitations that are causing
> this.
> But I have no idea how to support this in .NET Thin Client, for example.
>
> It is thread-safe and can handle multiple async operations in parallel.
> But with TX support we have to somehow switch to single-threaded mode to
> avoid unexpected effects.
>
> Any ideas?
>
>
> On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov 
> wrote:
>
> > Dmitriy, thank you!
> >
> > Guys, I've created the IEP [1] on wiki, please have a look.
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> >
> > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov :
> >
> > > Hi,
> > >
> > > I've added permissions to account plehanov.alex
> > >
> > > Recently Infra integrated Apache LDAP with confluence, so it is
> possible
> > to
> > > login using Apache credentials. Probably we can ask infra if extra
> > > permissions to edit pages should be added for committers.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov :
> > >
> > > > Vladimir,
> > > >
> > > > About current tx: ok, then we don't need tx() method in the interface
> > at
> > > > all (the same cached transaction info user can store by himself).
> > > >
> > > > About decoupling transactions from threads on the server side: for
> now,
> > > we
> > > > can start with thread-per-connection approach (we only can support
> one
> > > > active transaction per connection, see below, so we need one
> additional
> > > > dedicated thread for each connection with active transaction), and
> > later
> > > > change server-side internals to process client transactions in any
> > server
> > > > thread (not dedicated to this connection). This change will not
> affect
> > > the
> > > > thin client protocol, it only affects the server side.
> > > > In any case, we can't support concurrent transactions per connection
> on
> > > > the client side without fundamental changes to the current protocol
> > > (cache
> > > > operation doesn't bound to transaction or thread and the server
> doesn't
> > > > know which thread on the client side do this cache operation). In my
> > > > opinion, if a user wants to use concurrent transactions, he must use
> > > > different connections from a connection pool.
> > > >
> > > > About semantics of suspend/resume on the client-side: it's absolutely
> > > > different than server-side semantics (we don't need to do
> > suspend/resume
> > > to
> > > > pass transaction between threads on the client-side), but can't be
> > > > implemented efficiently without implemented suspend/resume on
> > > server-side.
> > > >
> > > > Can anyone give me permissions to create IEP on Apache wiki?
> > > >
> > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov :
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > My comments was only about the protocol. Getting current info about
> > > > > transaction should be handled by the client itself. It is not
> > protocl's
> > > > > concern. Same about other APIs and behavior in case another
> > transaction
> > > > is
> > > > > attempted from the same thread.
> > > > >
> > > > > Putting protocol aside, transaction support is complicated matter.
> I
> > > > would
> > > > > propose to route through IEP and wide community discussion. We need
> > to
> > > > > review API and semantics very carefully, taking SUSPEND/RESUME in
> > > count.
> > > > > Also I do not see how we support client transactions efficiently
> > > without
> > > > > decoupling transactions from threads on the server side first.
> > Because
> > > > > without it you will need a dedicated server thread for every
> client's
> > > > > transaction which is slow and may even crash the server.
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > > plehanov.a...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Vladimir, what if we want to get current transaction info (tx()
> > > > method)?
> > > > > >
> > > > > > Does close() method mapped to TX_END(rollback)?
> > > > > >
> > > > > > For example, this code:
> > > > > >
> > > > > > try(tx = txStart()) {
> > > > > > tx.commit();
> > > > > > }
> > > > > >
> > > > > > Will produce:
> > > > > > TX_START
> > > > > > TX_END(commit)
> > > > > > TX_END(rollback)
> > > > > >
> > > > > > Am I understand you right?
> > > > > >
> > > > > > About xid. There is yet another proposal. Use some unique per
> > > > connection
> > > > > id
> > > > > > (integer, simple counter) for identifying the transaction on
> > > > > > commit/rollback message. The client gets this id from the server
> > with
> > > 

Re: Thin client: transactions support

[Pavel Tupitsyn]

Alex,

> now we can only support one active transaction per connection

I totally understand server-side and protocol limitations that are causing
this.
But I have no idea how to support this in .NET Thin Client, for example.

It is thread-safe and can handle multiple async operations in parallel.
But with TX support we have to somehow switch to single-threaded mode to
avoid unexpected effects.

Any ideas?


On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov 
wrote:

> Dmitriy, thank you!
>
> Guys, I've created the IEP [1] on wiki, please have a look.
>
> [1]
>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
>
> чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov :
>
> > Hi,
> >
> > I've added permissions to account plehanov.alex
> >
> > Recently Infra integrated Apache LDAP with confluence, so it is possible
> to
> > login using Apache credentials. Probably we can ask infra if extra
> > permissions to edit pages should be added for committers.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov :
> >
> > > Vladimir,
> > >
> > > About current tx: ok, then we don't need tx() method in the interface
> at
> > > all (the same cached transaction info user can store by himself).
> > >
> > > About decoupling transactions from threads on the server side: for now,
> > we
> > > can start with thread-per-connection approach (we only can support one
> > > active transaction per connection, see below, so we need one additional
> > > dedicated thread for each connection with active transaction), and
> later
> > > change server-side internals to process client transactions in any
> server
> > > thread (not dedicated to this connection). This change will not affect
> > the
> > > thin client protocol, it only affects the server side.
> > > In any case, we can't support concurrent transactions per connection on
> > > the client side without fundamental changes to the current protocol
> > (cache
> > > operation doesn't bound to transaction or thread and the server doesn't
> > > know which thread on the client side do this cache operation). In my
> > > opinion, if a user wants to use concurrent transactions, he must use
> > > different connections from a connection pool.
> > >
> > > About semantics of suspend/resume on the client-side: it's absolutely
> > > different than server-side semantics (we don't need to do
> suspend/resume
> > to
> > > pass transaction between threads on the client-side), but can't be
> > > implemented efficiently without implemented suspend/resume on
> > server-side.
> > >
> > > Can anyone give me permissions to create IEP on Apache wiki?
> > >
> > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov :
> > >
> > > > Hi Alex,
> > > >
> > > > My comments was only about the protocol. Getting current info about
> > > > transaction should be handled by the client itself. It is not
> protocl's
> > > > concern. Same about other APIs and behavior in case another
> transaction
> > > is
> > > > attempted from the same thread.
> > > >
> > > > Putting protocol aside, transaction support is complicated matter. I
> > > would
> > > > propose to route through IEP and wide community discussion. We need
> to
> > > > review API and semantics very carefully, taking SUSPEND/RESUME in
> > count.
> > > > Also I do not see how we support client transactions efficiently
> > without
> > > > decoupling transactions from threads on the server side first.
> Because
> > > > without it you will need a dedicated server thread for every client's
> > > > transaction which is slow and may even crash the server.
> > > >
> > > > Vladimir.
> > > >
> > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > plehanov.a...@gmail.com>
> > > > wrote:
> > > >
> > > > > Vladimir, what if we want to get current transaction info (tx()
> > > method)?
> > > > >
> > > > > Does close() method mapped to TX_END(rollback)?
> > > > >
> > > > > For example, this code:
> > > > >
> > > > > try(tx = txStart()) {
> > > > > tx.commit();
> > > > > }
> > > > >
> > > > > Will produce:
> > > > > TX_START
> > > > > TX_END(commit)
> > > > > TX_END(rollback)
> > > > >
> > > > > Am I understand you right?
> > > > >
> > > > > About xid. There is yet another proposal. Use some unique per
> > > connection
> > > > id
> > > > > (integer, simple counter) for identifying the transaction on
> > > > > commit/rollback message. The client gets this id from the server
> with
> > > > > transaction info and sends it back to the server when trying to
> > > > > commit/rollback transaction. This id is not shown to users. But
> also
> > we
> > > > can
> > > > > pass from server to client real transaction id (xid) with
> transaction
> > > > info
> > > > > for diagnostic purposes.
> > > > >
> > > > > And one more question: what should we do if the client starts a new
> > > > > transaction without ending the old one? Should we end the old
> > > transaction
> > > > > implicitly (rollback) or throw an exception to the 

Re: Thin client: transactions support

[Alex Plehanov]

Dmitriy, thank you!

Guys, I've created the IEP [1] on wiki, please have a look.

[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support


чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov :

> Hi,
>
> I've added permissions to account plehanov.alex
>
> Recently Infra integrated Apache LDAP with confluence, so it is possible to
> login using Apache credentials. Probably we can ask infra if extra
> permissions to edit pages should be added for committers.
>
> Sincerely,
> Dmitriy Pavlov
>
> ср, 27 мар. 2019 г. в 13:37, Alex Plehanov :
>
> > Vladimir,
> >
> > About current tx: ok, then we don't need tx() method in the interface at
> > all (the same cached transaction info user can store by himself).
> >
> > About decoupling transactions from threads on the server side: for now,
> we
> > can start with thread-per-connection approach (we only can support one
> > active transaction per connection, see below, so we need one additional
> > dedicated thread for each connection with active transaction), and later
> > change server-side internals to process client transactions in any server
> > thread (not dedicated to this connection). This change will not affect
> the
> > thin client protocol, it only affects the server side.
> > In any case, we can't support concurrent transactions per connection on
> > the client side without fundamental changes to the current protocol
> (cache
> > operation doesn't bound to transaction or thread and the server doesn't
> > know which thread on the client side do this cache operation). In my
> > opinion, if a user wants to use concurrent transactions, he must use
> > different connections from a connection pool.
> >
> > About semantics of suspend/resume on the client-side: it's absolutely
> > different than server-side semantics (we don't need to do suspend/resume
> to
> > pass transaction between threads on the client-side), but can't be
> > implemented efficiently without implemented suspend/resume on
> server-side.
> >
> > Can anyone give me permissions to create IEP on Apache wiki?
> >
> > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov :
> >
> > > Hi Alex,
> > >
> > > My comments was only about the protocol. Getting current info about
> > > transaction should be handled by the client itself. It is not protocl's
> > > concern. Same about other APIs and behavior in case another transaction
> > is
> > > attempted from the same thread.
> > >
> > > Putting protocol aside, transaction support is complicated matter. I
> > would
> > > propose to route through IEP and wide community discussion. We need to
> > > review API and semantics very carefully, taking SUSPEND/RESUME in
> count.
> > > Also I do not see how we support client transactions efficiently
> without
> > > decoupling transactions from threads on the server side first. Because
> > > without it you will need a dedicated server thread for every client's
> > > transaction which is slow and may even crash the server.
> > >
> > > Vladimir.
> > >
> > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> plehanov.a...@gmail.com>
> > > wrote:
> > >
> > > > Vladimir, what if we want to get current transaction info (tx()
> > method)?
> > > >
> > > > Does close() method mapped to TX_END(rollback)?
> > > >
> > > > For example, this code:
> > > >
> > > > try(tx = txStart()) {
> > > > tx.commit();
> > > > }
> > > >
> > > > Will produce:
> > > > TX_START
> > > > TX_END(commit)
> > > > TX_END(rollback)
> > > >
> > > > Am I understand you right?
> > > >
> > > > About xid. There is yet another proposal. Use some unique per
> > connection
> > > id
> > > > (integer, simple counter) for identifying the transaction on
> > > > commit/rollback message. The client gets this id from the server with
> > > > transaction info and sends it back to the server when trying to
> > > > commit/rollback transaction. This id is not shown to users. But also
> we
> > > can
> > > > pass from server to client real transaction id (xid) with transaction
> > > info
> > > > for diagnostic purposes.
> > > >
> > > > And one more question: what should we do if the client starts a new
> > > > transaction without ending the old one? Should we end the old
> > transaction
> > > > implicitly (rollback) or throw an exception to the client? In my
> > opinion,
> > > > the first option is better. For example, if we got a previously used
> > > > connection from the connection pool, we should not worry about any
> > > > uncompleted transaction started by the previous user of this
> > connection.
> > > >
> > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov :
> > > >
> > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet,
> and
> > > > adding
> > > > > them in future should not conflict with simple START/END
> > > infrastructure.
> > > > >
> > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> > voze...@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hi Alex,
> > > > > >
> > > > > > I am not sure we need 5 

Re: Thin client: transactions support

[Dmitriy Pavlov]

Hi,

I've added permissions to account plehanov.alex

Recently Infra integrated Apache LDAP with confluence, so it is possible to
login using Apache credentials. Probably we can ask infra if extra
permissions to edit pages should be added for committers.

Sincerely,
Dmitriy Pavlov

ср, 27 мар. 2019 г. в 13:37, Alex Plehanov :

> Vladimir,
>
> About current tx: ok, then we don't need tx() method in the interface at
> all (the same cached transaction info user can store by himself).
>
> About decoupling transactions from threads on the server side: for now, we
> can start with thread-per-connection approach (we only can support one
> active transaction per connection, see below, so we need one additional
> dedicated thread for each connection with active transaction), and later
> change server-side internals to process client transactions in any server
> thread (not dedicated to this connection). This change will not affect the
> thin client protocol, it only affects the server side.
> In any case, we can't support concurrent transactions per connection on
> the client side without fundamental changes to the current protocol (cache
> operation doesn't bound to transaction or thread and the server doesn't
> know which thread on the client side do this cache operation). In my
> opinion, if a user wants to use concurrent transactions, he must use
> different connections from a connection pool.
>
> About semantics of suspend/resume on the client-side: it's absolutely
> different than server-side semantics (we don't need to do suspend/resume to
> pass transaction between threads on the client-side), but can't be
> implemented efficiently without implemented suspend/resume on server-side.
>
> Can anyone give me permissions to create IEP on Apache wiki?
>
> ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov :
>
> > Hi Alex,
> >
> > My comments was only about the protocol. Getting current info about
> > transaction should be handled by the client itself. It is not protocl's
> > concern. Same about other APIs and behavior in case another transaction
> is
> > attempted from the same thread.
> >
> > Putting protocol aside, transaction support is complicated matter. I
> would
> > propose to route through IEP and wide community discussion. We need to
> > review API and semantics very carefully, taking SUSPEND/RESUME in count.
> > Also I do not see how we support client transactions efficiently without
> > decoupling transactions from threads on the server side first. Because
> > without it you will need a dedicated server thread for every client's
> > transaction which is slow and may even crash the server.
> >
> > Vladimir.
> >
> > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov 
> > wrote:
> >
> > > Vladimir, what if we want to get current transaction info (tx()
> method)?
> > >
> > > Does close() method mapped to TX_END(rollback)?
> > >
> > > For example, this code:
> > >
> > > try(tx = txStart()) {
> > > tx.commit();
> > > }
> > >
> > > Will produce:
> > > TX_START
> > > TX_END(commit)
> > > TX_END(rollback)
> > >
> > > Am I understand you right?
> > >
> > > About xid. There is yet another proposal. Use some unique per
> connection
> > id
> > > (integer, simple counter) for identifying the transaction on
> > > commit/rollback message. The client gets this id from the server with
> > > transaction info and sends it back to the server when trying to
> > > commit/rollback transaction. This id is not shown to users. But also we
> > can
> > > pass from server to client real transaction id (xid) with transaction
> > info
> > > for diagnostic purposes.
> > >
> > > And one more question: what should we do if the client starts a new
> > > transaction without ending the old one? Should we end the old
> transaction
> > > implicitly (rollback) or throw an exception to the client? In my
> opinion,
> > > the first option is better. For example, if we got a previously used
> > > connection from the connection pool, we should not worry about any
> > > uncompleted transaction started by the previous user of this
> connection.
> > >
> > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov :
> > >
> > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and
> > > adding
> > > > them in future should not conflict with simple START/END
> > infrastructure.
> > > >
> > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> voze...@gridgain.com
> > >
> > > > wrote:
> > > >
> > > > > Hi Alex,
> > > > >
> > > > > I am not sure we need 5 commands. Wouldn't it be enough to have
> only
> > > two?
> > > > >
> > > > > START - accepts optional parameters, returns transaction info
> > > > > END - provides commit flag, returns void
> > > > >
> > > > > Vladimir.
> > > > >
> > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> > plehanov.a...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> Sergey, yes, the close is something like silent rollback. But we
> can
> > > > >> also implement this on the client side, just using rollback 

Re: Thin client: transactions support

[Alex Plehanov]

Vladimir,

About current tx: ok, then we don't need tx() method in the interface at
all (the same cached transaction info user can store by himself).

About decoupling transactions from threads on the server side: for now, we
can start with thread-per-connection approach (we only can support one
active transaction per connection, see below, so we need one additional
dedicated thread for each connection with active transaction), and later
change server-side internals to process client transactions in any server
thread (not dedicated to this connection). This change will not affect the
thin client protocol, it only affects the server side.
In any case, we can't support concurrent transactions per connection on
the client side without fundamental changes to the current protocol (cache
operation doesn't bound to transaction or thread and the server doesn't
know which thread on the client side do this cache operation). In my
opinion, if a user wants to use concurrent transactions, he must use
different connections from a connection pool.

About semantics of suspend/resume on the client-side: it's absolutely
different than server-side semantics (we don't need to do suspend/resume to
pass transaction between threads on the client-side), but can't be
implemented efficiently without implemented suspend/resume on server-side.

Can anyone give me permissions to create IEP on Apache wiki?

ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov :

> Hi Alex,
>
> My comments was only about the protocol. Getting current info about
> transaction should be handled by the client itself. It is not protocl's
> concern. Same about other APIs and behavior in case another transaction is
> attempted from the same thread.
>
> Putting protocol aside, transaction support is complicated matter. I would
> propose to route through IEP and wide community discussion. We need to
> review API and semantics very carefully, taking SUSPEND/RESUME in count.
> Also I do not see how we support client transactions efficiently without
> decoupling transactions from threads on the server side first. Because
> without it you will need a dedicated server thread for every client's
> transaction which is slow and may even crash the server.
>
> Vladimir.
>
> On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov 
> wrote:
>
> > Vladimir, what if we want to get current transaction info (tx() method)?
> >
> > Does close() method mapped to TX_END(rollback)?
> >
> > For example, this code:
> >
> > try(tx = txStart()) {
> > tx.commit();
> > }
> >
> > Will produce:
> > TX_START
> > TX_END(commit)
> > TX_END(rollback)
> >
> > Am I understand you right?
> >
> > About xid. There is yet another proposal. Use some unique per connection
> id
> > (integer, simple counter) for identifying the transaction on
> > commit/rollback message. The client gets this id from the server with
> > transaction info and sends it back to the server when trying to
> > commit/rollback transaction. This id is not shown to users. But also we
> can
> > pass from server to client real transaction id (xid) with transaction
> info
> > for diagnostic purposes.
> >
> > And one more question: what should we do if the client starts a new
> > transaction without ending the old one? Should we end the old transaction
> > implicitly (rollback) or throw an exception to the client? In my opinion,
> > the first option is better. For example, if we got a previously used
> > connection from the connection pool, we should not worry about any
> > uncompleted transaction started by the previous user of this connection.
> >
> > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov :
> >
> > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and
> > adding
> > > them in future should not conflict with simple START/END
> infrastructure.
> > >
> > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov  >
> > > wrote:
> > >
> > > > Hi Alex,
> > > >
> > > > I am not sure we need 5 commands. Wouldn't it be enough to have only
> > two?
> > > >
> > > > START - accepts optional parameters, returns transaction info
> > > > END - provides commit flag, returns void
> > > >
> > > > Vladimir.
> > > >
> > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> plehanov.a...@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Sergey, yes, the close is something like silent rollback. But we can
> > > >> also implement this on the client side, just using rollback and
> > ignoring
> > > >> errors in the response.
> > > >>
> > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :
> > > >>
> > > >> > Nikolay
> > > >> >
> > > >> > Am I correctly understand you points:
> > > >> >
> > > >> >- close: rollback
> > > >> >- commit, close: do nothing
> > > >> >- rollback, close: do what? (I suppose nothing)
> > > >> >
> > > >> > Also you assume that after commit/rollback we may need to free
> some
> > > >> > resources on server node(s)or just do on client started TX?
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Tue, Mar 26, 2019 at 10:41 PM 

Re: Thin client: transactions support

[Vladimir Ozerov]

Hi Alex,

My comments was only about the protocol. Getting current info about
transaction should be handled by the client itself. It is not protocl's
concern. Same about other APIs and behavior in case another transaction is
attempted from the same thread.

Putting protocol aside, transaction support is complicated matter. I would
propose to route through IEP and wide community discussion. We need to
review API and semantics very carefully, taking SUSPEND/RESUME in count.
Also I do not see how we support client transactions efficiently without
decoupling transactions from threads on the server side first. Because
without it you will need a dedicated server thread for every client's
transaction which is slow and may even crash the server.

Vladimir.

On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov 
wrote:

> Vladimir, what if we want to get current transaction info (tx() method)?
>
> Does close() method mapped to TX_END(rollback)?
>
> For example, this code:
>
> try(tx = txStart()) {
> tx.commit();
> }
>
> Will produce:
> TX_START
> TX_END(commit)
> TX_END(rollback)
>
> Am I understand you right?
>
> About xid. There is yet another proposal. Use some unique per connection id
> (integer, simple counter) for identifying the transaction on
> commit/rollback message. The client gets this id from the server with
> transaction info and sends it back to the server when trying to
> commit/rollback transaction. This id is not shown to users. But also we can
> pass from server to client real transaction id (xid) with transaction info
> for diagnostic purposes.
>
> And one more question: what should we do if the client starts a new
> transaction without ending the old one? Should we end the old transaction
> implicitly (rollback) or throw an exception to the client? In my opinion,
> the first option is better. For example, if we got a previously used
> connection from the connection pool, we should not worry about any
> uncompleted transaction started by the previous user of this connection.
>
> ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov :
>
> > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and
> adding
> > them in future should not conflict with simple START/END infrastructure.
> >
> > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov 
> > wrote:
> >
> > > Hi Alex,
> > >
> > > I am not sure we need 5 commands. Wouldn't it be enough to have only
> two?
> > >
> > > START - accepts optional parameters, returns transaction info
> > > END - provides commit flag, returns void
> > >
> > > Vladimir.
> > >
> > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov  >
> > > wrote:
> > >
> > >> Sergey, yes, the close is something like silent rollback. But we can
> > >> also implement this on the client side, just using rollback and
> ignoring
> > >> errors in the response.
> > >>
> > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :
> > >>
> > >> > Nikolay
> > >> >
> > >> > Am I correctly understand you points:
> > >> >
> > >> >- close: rollback
> > >> >- commit, close: do nothing
> > >> >- rollback, close: do what? (I suppose nothing)
> > >> >
> > >> > Also you assume that after commit/rollback we may need to free some
> > >> > resources on server node(s)or just do on client started TX?
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
> > plehanov.a...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> > > Sergey, we have the close() method in the thick client, it's
> > behavior
> > >> is
> > >> > > slightly different than rollback() method (it should rollback if
> the
> > >> > > transaction is not committed and do nothing if the transaction is
> > >> already
> > >> > > committed). I think we should support try-with-resource semantics
> in
> > >> the
> > >> > > thin client and OP_TX_CLOSE will be useful here.
> > >> > >
> > >> > > Nikolay, suspend/resume didn't work yet for pessimistic
> > transactions.
> > >> > Also,
> > >> > > the main goal of suspend/resume operations is to support
> transaction
> > >> > > passing between threads. In the thin client, the transaction is
> > bound
> > >> to
> > >> > > the client connection, not client thread. I think passing a
> > >> transaction
> > >> > > between different client connections is not a very useful case.
> > >> > >
> > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov  >:
> > >> > >
> > >> > > > Hello, Alex.
> > >> > > >
> > >> > > > We also have suspend and resume operations.
> > >> > > > I think we should support them
> > >> > > >
> > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov  >:
> > >> > > >
> > >> > > > > Hi
> > >> > > > >
> > >> > > > > Looks like I missed something but why we need OP_TX_CLOSE
> > >> operation?
> > >> > > > >
> > >> > > > > Also I suggest to reserve a code for SAVEPOINT operation which
> > >> very
> > >> > > > useful
> > >> > > > > to understand where transaction has been rolled back
> > >> > > > >
> > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
> > >> > 

Re: Thin client: transactions support

[Alex Plehanov]

Vladimir, what if we want to get current transaction info (tx() method)?

Does close() method mapped to TX_END(rollback)?

For example, this code:

try(tx = txStart()) {
tx.commit();
}

Will produce:
TX_START
TX_END(commit)
TX_END(rollback)

Am I understand you right?

About xid. There is yet another proposal. Use some unique per connection id
(integer, simple counter) for identifying the transaction on
commit/rollback message. The client gets this id from the server with
transaction info and sends it back to the server when trying to
commit/rollback transaction. This id is not shown to users. But also we can
pass from server to client real transaction id (xid) with transaction info
for diagnostic purposes.

And one more question: what should we do if the client starts a new
transaction without ending the old one? Should we end the old transaction
implicitly (rollback) or throw an exception to the client? In my opinion,
the first option is better. For example, if we got a previously used
connection from the connection pool, we should not worry about any
uncompleted transaction started by the previous user of this connection.

ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov :

> As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and adding
> them in future should not conflict with simple START/END infrastructure.
>
> On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov 
> wrote:
>
> > Hi Alex,
> >
> > I am not sure we need 5 commands. Wouldn't it be enough to have only two?
> >
> > START - accepts optional parameters, returns transaction info
> > END - provides commit flag, returns void
> >
> > Vladimir.
> >
> > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov 
> > wrote:
> >
> >> Sergey, yes, the close is something like silent rollback. But we can
> >> also implement this on the client side, just using rollback and ignoring
> >> errors in the response.
> >>
> >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :
> >>
> >> > Nikolay
> >> >
> >> > Am I correctly understand you points:
> >> >
> >> >- close: rollback
> >> >- commit, close: do nothing
> >> >- rollback, close: do what? (I suppose nothing)
> >> >
> >> > Also you assume that after commit/rollback we may need to free some
> >> > resources on server node(s)or just do on client started TX?
> >> >
> >> >
> >> >
> >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
> plehanov.a...@gmail.com
> >> >
> >> > wrote:
> >> >
> >> > > Sergey, we have the close() method in the thick client, it's
> behavior
> >> is
> >> > > slightly different than rollback() method (it should rollback if the
> >> > > transaction is not committed and do nothing if the transaction is
> >> already
> >> > > committed). I think we should support try-with-resource semantics in
> >> the
> >> > > thin client and OP_TX_CLOSE will be useful here.
> >> > >
> >> > > Nikolay, suspend/resume didn't work yet for pessimistic
> transactions.
> >> > Also,
> >> > > the main goal of suspend/resume operations is to support transaction
> >> > > passing between threads. In the thin client, the transaction is
> bound
> >> to
> >> > > the client connection, not client thread. I think passing a
> >> transaction
> >> > > between different client connections is not a very useful case.
> >> > >
> >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov :
> >> > >
> >> > > > Hello, Alex.
> >> > > >
> >> > > > We also have suspend and resume operations.
> >> > > > I think we should support them
> >> > > >
> >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
> >> > > >
> >> > > > > Hi
> >> > > > >
> >> > > > > Looks like I missed something but why we need OP_TX_CLOSE
> >> operation?
> >> > > > >
> >> > > > > Also I suggest to reserve a code for SAVEPOINT operation which
> >> very
> >> > > > useful
> >> > > > > to understand where transaction has been rolled back
> >> > > > >
> >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
> >> > plehanov.a...@gmail.com
> >> > > >
> >> > > > > wrote:
> >> > > > >
> >> > > > > > Hello Igniters!
> >> > > > > >
> >> > > > > > I want to pick up the ticket IGNITE-7369 and add transactions
> >> > support
> >> > > > to
> >> > > > > > our thin client implementation.
> >> > > > > > I've looked at our current implementation and have some
> >> proposals
> >> > to
> >> > > > > > support transactions:
> >> > > > > >
> >> > > > > > Add new operations to thin client protocol:
> >> > > > > >
> >> > > > > > OP_TX_GET, 4000, Get current transaction for client
> >> connection
> >> > > > > > OP_TX_START, 4001, Start a new transaction
> >> > > > > > OP_TX_COMMIT, 4002, Commit transaction
> >> > > > > > OP_TX_ROLLBACK, 4003, Rollback transaction
> >> > > > > > OP_TX_CLOSE, 4004, Close transaction
> >> > > > > >
> >> > > > > > From the client side (java) new interfaces will be added:
> >> > > > > >
> >> > > > > > public interface ClientTransactions {
> >> > > > > > public ClientTransaction txStart();
> >> > > > > > public ClientTransaction 

Re: Thin client: transactions support

[Vladimir Ozerov]

As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and adding
them in future should not conflict with simple START/END infrastructure.

On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov 
wrote:

> Hi Alex,
>
> I am not sure we need 5 commands. Wouldn't it be enough to have only two?
>
> START - accepts optional parameters, returns transaction info
> END - provides commit flag, returns void
>
> Vladimir.
>
> On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov 
> wrote:
>
>> Sergey, yes, the close is something like silent rollback. But we can
>> also implement this on the client side, just using rollback and ignoring
>> errors in the response.
>>
>> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :
>>
>> > Nikolay
>> >
>> > Am I correctly understand you points:
>> >
>> >- close: rollback
>> >- commit, close: do nothing
>> >- rollback, close: do what? (I suppose nothing)
>> >
>> > Also you assume that after commit/rollback we may need to free some
>> > resources on server node(s)or just do on client started TX?
>> >
>> >
>> >
>> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov > >
>> > wrote:
>> >
>> > > Sergey, we have the close() method in the thick client, it's behavior
>> is
>> > > slightly different than rollback() method (it should rollback if the
>> > > transaction is not committed and do nothing if the transaction is
>> already
>> > > committed). I think we should support try-with-resource semantics in
>> the
>> > > thin client and OP_TX_CLOSE will be useful here.
>> > >
>> > > Nikolay, suspend/resume didn't work yet for pessimistic transactions.
>> > Also,
>> > > the main goal of suspend/resume operations is to support transaction
>> > > passing between threads. In the thin client, the transaction is bound
>> to
>> > > the client connection, not client thread. I think passing a
>> transaction
>> > > between different client connections is not a very useful case.
>> > >
>> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov :
>> > >
>> > > > Hello, Alex.
>> > > >
>> > > > We also have suspend and resume operations.
>> > > > I think we should support them
>> > > >
>> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
>> > > >
>> > > > > Hi
>> > > > >
>> > > > > Looks like I missed something but why we need OP_TX_CLOSE
>> operation?
>> > > > >
>> > > > > Also I suggest to reserve a code for SAVEPOINT operation which
>> very
>> > > > useful
>> > > > > to understand where transaction has been rolled back
>> > > > >
>> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
>> > plehanov.a...@gmail.com
>> > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Hello Igniters!
>> > > > > >
>> > > > > > I want to pick up the ticket IGNITE-7369 and add transactions
>> > support
>> > > > to
>> > > > > > our thin client implementation.
>> > > > > > I've looked at our current implementation and have some
>> proposals
>> > to
>> > > > > > support transactions:
>> > > > > >
>> > > > > > Add new operations to thin client protocol:
>> > > > > >
>> > > > > > OP_TX_GET, 4000, Get current transaction for client
>> connection
>> > > > > > OP_TX_START, 4001, Start a new transaction
>> > > > > > OP_TX_COMMIT, 4002, Commit transaction
>> > > > > > OP_TX_ROLLBACK, 4003, Rollback transaction
>> > > > > > OP_TX_CLOSE, 4004, Close transaction
>> > > > > >
>> > > > > > From the client side (java) new interfaces will be added:
>> > > > > >
>> > > > > > public interface ClientTransactions {
>> > > > > > public ClientTransaction txStart();
>> > > > > > public ClientTransaction txStart(TransactionConcurrency
>> > > > concurrency,
>> > > > > > TransactionIsolation isolation);
>> > > > > > public ClientTransaction txStart(TransactionConcurrency
>> > > > concurrency,
>> > > > > > TransactionIsolation isolation, long timeout, int txSize);
>> > > > > > public ClientTransaction tx(); // Get current connection
>> > > > transaction
>> > > > > > public ClientTransactions withLabel(String lb);
>> > > > > > }
>> > > > > >
>> > > > > > public interface ClientTransaction extends AutoCloseable {
>> > > > > > public IgniteUuid xid(); // Do we need it?
>> > > > > > public TransactionIsolation isolation();
>> > > > > > public TransactionConcurrency concurrency();
>> > > > > > public long timeout();
>> > > > > > public String label();
>> > > > > >
>> > > > > > public void commit();
>> > > > > > public void rollback();
>> > > > > > public void close();
>> > > > > > }
>> > > > > >
>> > > > > > From the server side, I think as a first step (while
>> transactions
>> > > > > > suspend/resume is not fully implemented) we can use the same
>> > approach
>> > > > as
>> > > > > > for JDBC: add a new worker to each ClientRequestHandler and
>> process
>> > > > > > requests by this worker if the transaction is started
>> explicitly.
>> > > > > > ClientRequestHandler is bound to client connection, so there
>> will
>> > be
>> > > > 1:1
>> > > > > > relation between client connection and 

Re: Thin client: transactions support

[Vladimir Ozerov]

Hi Alex,

I am not sure we need 5 commands. Wouldn't it be enough to have only two?

START - accepts optional parameters, returns transaction info
END - provides commit flag, returns void

Vladimir.

On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov 
wrote:

> Sergey, yes, the close is something like silent rollback. But we can
> also implement this on the client side, just using rollback and ignoring
> errors in the response.
>
> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :
>
> > Nikolay
> >
> > Am I correctly understand you points:
> >
> >- close: rollback
> >- commit, close: do nothing
> >- rollback, close: do what? (I suppose nothing)
> >
> > Also you assume that after commit/rollback we may need to free some
> > resources on server node(s)or just do on client started TX?
> >
> >
> >
> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov 
> > wrote:
> >
> > > Sergey, we have the close() method in the thick client, it's behavior
> is
> > > slightly different than rollback() method (it should rollback if the
> > > transaction is not committed and do nothing if the transaction is
> already
> > > committed). I think we should support try-with-resource semantics in
> the
> > > thin client and OP_TX_CLOSE will be useful here.
> > >
> > > Nikolay, suspend/resume didn't work yet for pessimistic transactions.
> > Also,
> > > the main goal of suspend/resume operations is to support transaction
> > > passing between threads. In the thin client, the transaction is bound
> to
> > > the client connection, not client thread. I think passing a transaction
> > > between different client connections is not a very useful case.
> > >
> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov :
> > >
> > > > Hello, Alex.
> > > >
> > > > We also have suspend and resume operations.
> > > > I think we should support them
> > > >
> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
> > > >
> > > > > Hi
> > > > >
> > > > > Looks like I missed something but why we need OP_TX_CLOSE
> operation?
> > > > >
> > > > > Also I suggest to reserve a code for SAVEPOINT operation which very
> > > > useful
> > > > > to understand where transaction has been rolled back
> > > > >
> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
> > plehanov.a...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Hello Igniters!
> > > > > >
> > > > > > I want to pick up the ticket IGNITE-7369 and add transactions
> > support
> > > > to
> > > > > > our thin client implementation.
> > > > > > I've looked at our current implementation and have some proposals
> > to
> > > > > > support transactions:
> > > > > >
> > > > > > Add new operations to thin client protocol:
> > > > > >
> > > > > > OP_TX_GET, 4000, Get current transaction for client
> connection
> > > > > > OP_TX_START, 4001, Start a new transaction
> > > > > > OP_TX_COMMIT, 4002, Commit transaction
> > > > > > OP_TX_ROLLBACK, 4003, Rollback transaction
> > > > > > OP_TX_CLOSE, 4004, Close transaction
> > > > > >
> > > > > > From the client side (java) new interfaces will be added:
> > > > > >
> > > > > > public interface ClientTransactions {
> > > > > > public ClientTransaction txStart();
> > > > > > public ClientTransaction txStart(TransactionConcurrency
> > > > concurrency,
> > > > > > TransactionIsolation isolation);
> > > > > > public ClientTransaction txStart(TransactionConcurrency
> > > > concurrency,
> > > > > > TransactionIsolation isolation, long timeout, int txSize);
> > > > > > public ClientTransaction tx(); // Get current connection
> > > > transaction
> > > > > > public ClientTransactions withLabel(String lb);
> > > > > > }
> > > > > >
> > > > > > public interface ClientTransaction extends AutoCloseable {
> > > > > > public IgniteUuid xid(); // Do we need it?
> > > > > > public TransactionIsolation isolation();
> > > > > > public TransactionConcurrency concurrency();
> > > > > > public long timeout();
> > > > > > public String label();
> > > > > >
> > > > > > public void commit();
> > > > > > public void rollback();
> > > > > > public void close();
> > > > > > }
> > > > > >
> > > > > > From the server side, I think as a first step (while transactions
> > > > > > suspend/resume is not fully implemented) we can use the same
> > approach
> > > > as
> > > > > > for JDBC: add a new worker to each ClientRequestHandler and
> process
> > > > > > requests by this worker if the transaction is started explicitly.
> > > > > > ClientRequestHandler is bound to client connection, so there will
> > be
> > > > 1:1
> > > > > > relation between client connection and thread, which process
> > > operations
> > > > > in
> > > > > > a transaction.
> > > > > >
> > > > > > Also, there is a couple of issues I want to discuss:
> > > > > >
> > > > > > We have overloaded method txStart with a different set of
> > arguments.
> > > > Some
> > > > > > of the arguments may be missing. To pass arguments with
> OP_TX_START
> > > > > > operation 

Re: Thin client: transactions support

[Alex Plehanov]

Sergey, yes, the close is something like silent rollback. But we can
also implement this on the client side, just using rollback and ignoring
errors in the response.

ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov :

> Nikolay
>
> Am I correctly understand you points:
>
>- close: rollback
>- commit, close: do nothing
>- rollback, close: do what? (I suppose nothing)
>
> Also you assume that after commit/rollback we may need to free some
> resources on server node(s)or just do on client started TX?
>
>
>
> On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov 
> wrote:
>
> > Sergey, we have the close() method in the thick client, it's behavior is
> > slightly different than rollback() method (it should rollback if the
> > transaction is not committed and do nothing if the transaction is already
> > committed). I think we should support try-with-resource semantics in the
> > thin client and OP_TX_CLOSE will be useful here.
> >
> > Nikolay, suspend/resume didn't work yet for pessimistic transactions.
> Also,
> > the main goal of suspend/resume operations is to support transaction
> > passing between threads. In the thin client, the transaction is bound to
> > the client connection, not client thread. I think passing a transaction
> > between different client connections is not a very useful case.
> >
> > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov :
> >
> > > Hello, Alex.
> > >
> > > We also have suspend and resume operations.
> > > I think we should support them
> > >
> > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
> > >
> > > > Hi
> > > >
> > > > Looks like I missed something but why we need OP_TX_CLOSE operation?
> > > >
> > > > Also I suggest to reserve a code for SAVEPOINT operation which very
> > > useful
> > > > to understand where transaction has been rolled back
> > > >
> > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
> plehanov.a...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello Igniters!
> > > > >
> > > > > I want to pick up the ticket IGNITE-7369 and add transactions
> support
> > > to
> > > > > our thin client implementation.
> > > > > I've looked at our current implementation and have some proposals
> to
> > > > > support transactions:
> > > > >
> > > > > Add new operations to thin client protocol:
> > > > >
> > > > > OP_TX_GET, 4000, Get current transaction for client connection
> > > > > OP_TX_START, 4001, Start a new transaction
> > > > > OP_TX_COMMIT, 4002, Commit transaction
> > > > > OP_TX_ROLLBACK, 4003, Rollback transaction
> > > > > OP_TX_CLOSE, 4004, Close transaction
> > > > >
> > > > > From the client side (java) new interfaces will be added:
> > > > >
> > > > > public interface ClientTransactions {
> > > > > public ClientTransaction txStart();
> > > > > public ClientTransaction txStart(TransactionConcurrency
> > > concurrency,
> > > > > TransactionIsolation isolation);
> > > > > public ClientTransaction txStart(TransactionConcurrency
> > > concurrency,
> > > > > TransactionIsolation isolation, long timeout, int txSize);
> > > > > public ClientTransaction tx(); // Get current connection
> > > transaction
> > > > > public ClientTransactions withLabel(String lb);
> > > > > }
> > > > >
> > > > > public interface ClientTransaction extends AutoCloseable {
> > > > > public IgniteUuid xid(); // Do we need it?
> > > > > public TransactionIsolation isolation();
> > > > > public TransactionConcurrency concurrency();
> > > > > public long timeout();
> > > > > public String label();
> > > > >
> > > > > public void commit();
> > > > > public void rollback();
> > > > > public void close();
> > > > > }
> > > > >
> > > > > From the server side, I think as a first step (while transactions
> > > > > suspend/resume is not fully implemented) we can use the same
> approach
> > > as
> > > > > for JDBC: add a new worker to each ClientRequestHandler and process
> > > > > requests by this worker if the transaction is started explicitly.
> > > > > ClientRequestHandler is bound to client connection, so there will
> be
> > > 1:1
> > > > > relation between client connection and thread, which process
> > operations
> > > > in
> > > > > a transaction.
> > > > >
> > > > > Also, there is a couple of issues I want to discuss:
> > > > >
> > > > > We have overloaded method txStart with a different set of
> arguments.
> > > Some
> > > > > of the arguments may be missing. To pass arguments with OP_TX_START
> > > > > operation we have the next options:
> > > > >  * Serialize full set of arguments and use some value for missing
> > > > > arguments. For example -1 for int/long types and null for string
> > type.
> > > We
> > > > > can't use 0 for int/long types since 0 it's a valid value for
> > > > concurrency,
> > > > > isolation and timeout arguments.
> > > > >  * Serialize arguments as a collection of property-value pairs
> (like
> > > it's
> > > > > implemented now for CacheConfiguration). In this case only
> explicitly
> > > > > 

Re: Thin client: transactions support

[Sergey Kozlov]

Nikolay

Am I correctly understand you points:

   - close: rollback
   - commit, close: do nothing
   - rollback, close: do what? (I suppose nothing)

Also you assume that after commit/rollback we may need to free some
resources on server node(s)or just do on client started TX?



On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov 
wrote:

> Sergey, we have the close() method in the thick client, it's behavior is
> slightly different than rollback() method (it should rollback if the
> transaction is not committed and do nothing if the transaction is already
> committed). I think we should support try-with-resource semantics in the
> thin client and OP_TX_CLOSE will be useful here.
>
> Nikolay, suspend/resume didn't work yet for pessimistic transactions. Also,
> the main goal of suspend/resume operations is to support transaction
> passing between threads. In the thin client, the transaction is bound to
> the client connection, not client thread. I think passing a transaction
> between different client connections is not a very useful case.
>
> вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov :
>
> > Hello, Alex.
> >
> > We also have suspend and resume operations.
> > I think we should support them
> >
> > вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
> >
> > > Hi
> > >
> > > Looks like I missed something but why we need OP_TX_CLOSE operation?
> > >
> > > Also I suggest to reserve a code for SAVEPOINT operation which very
> > useful
> > > to understand where transaction has been rolled back
> > >
> > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov  >
> > > wrote:
> > >
> > > > Hello Igniters!
> > > >
> > > > I want to pick up the ticket IGNITE-7369 and add transactions support
> > to
> > > > our thin client implementation.
> > > > I've looked at our current implementation and have some proposals to
> > > > support transactions:
> > > >
> > > > Add new operations to thin client protocol:
> > > >
> > > > OP_TX_GET, 4000, Get current transaction for client connection
> > > > OP_TX_START, 4001, Start a new transaction
> > > > OP_TX_COMMIT, 4002, Commit transaction
> > > > OP_TX_ROLLBACK, 4003, Rollback transaction
> > > > OP_TX_CLOSE, 4004, Close transaction
> > > >
> > > > From the client side (java) new interfaces will be added:
> > > >
> > > > public interface ClientTransactions {
> > > > public ClientTransaction txStart();
> > > > public ClientTransaction txStart(TransactionConcurrency
> > concurrency,
> > > > TransactionIsolation isolation);
> > > > public ClientTransaction txStart(TransactionConcurrency
> > concurrency,
> > > > TransactionIsolation isolation, long timeout, int txSize);
> > > > public ClientTransaction tx(); // Get current connection
> > transaction
> > > > public ClientTransactions withLabel(String lb);
> > > > }
> > > >
> > > > public interface ClientTransaction extends AutoCloseable {
> > > > public IgniteUuid xid(); // Do we need it?
> > > > public TransactionIsolation isolation();
> > > > public TransactionConcurrency concurrency();
> > > > public long timeout();
> > > > public String label();
> > > >
> > > > public void commit();
> > > > public void rollback();
> > > > public void close();
> > > > }
> > > >
> > > > From the server side, I think as a first step (while transactions
> > > > suspend/resume is not fully implemented) we can use the same approach
> > as
> > > > for JDBC: add a new worker to each ClientRequestHandler and process
> > > > requests by this worker if the transaction is started explicitly.
> > > > ClientRequestHandler is bound to client connection, so there will be
> > 1:1
> > > > relation between client connection and thread, which process
> operations
> > > in
> > > > a transaction.
> > > >
> > > > Also, there is a couple of issues I want to discuss:
> > > >
> > > > We have overloaded method txStart with a different set of arguments.
> > Some
> > > > of the arguments may be missing. To pass arguments with OP_TX_START
> > > > operation we have the next options:
> > > >  * Serialize full set of arguments and use some value for missing
> > > > arguments. For example -1 for int/long types and null for string
> type.
> > We
> > > > can't use 0 for int/long types since 0 it's a valid value for
> > > concurrency,
> > > > isolation and timeout arguments.
> > > >  * Serialize arguments as a collection of property-value pairs (like
> > it's
> > > > implemented now for CacheConfiguration). In this case only explicitly
> > > > provided arguments will be serialized.
> > > > Which way is better? The simplest solution is to use the first option
> > > and I
> > > > want to use it if there were no objections.
> > > >
> > > > Do we need transaction id (xid) on the client side?
> > > > If yes, we can pass xid along with OP_TX_COMMIT, OP_TX_ROLLBACK,
> > > > OP_TX_CLOSE operations back to the server and do additional check on
> > the
> > > > server side (current transaction id for connection == transaction id
> > > 

Re: Thin client: transactions support

[Alex Plehanov]

Sergey, we have the close() method in the thick client, it's behavior is
slightly different than rollback() method (it should rollback if the
transaction is not committed and do nothing if the transaction is already
committed). I think we should support try-with-resource semantics in the
thin client and OP_TX_CLOSE will be useful here.

Nikolay, suspend/resume didn't work yet for pessimistic transactions. Also,
the main goal of suspend/resume operations is to support transaction
passing between threads. In the thin client, the transaction is bound to
the client connection, not client thread. I think passing a transaction
between different client connections is not a very useful case.

вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov :

> Hello, Alex.
>
> We also have suspend and resume operations.
> I think we should support them
>
> вт, 26 марта 2019 г., 22:07 Sergey Kozlov :
>
> > Hi
> >
> > Looks like I missed something but why we need OP_TX_CLOSE operation?
> >
> > Also I suggest to reserve a code for SAVEPOINT operation which very
> useful
> > to understand where transaction has been rolled back
> >
> > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov 
> > wrote:
> >
> > > Hello Igniters!
> > >
> > > I want to pick up the ticket IGNITE-7369 and add transactions support
> to
> > > our thin client implementation.
> > > I've looked at our current implementation and have some proposals to
> > > support transactions:
> > >
> > > Add new operations to thin client protocol:
> > >
> > > OP_TX_GET, 4000, Get current transaction for client connection
> > > OP_TX_START, 4001, Start a new transaction
> > > OP_TX_COMMIT, 4002, Commit transaction
> > > OP_TX_ROLLBACK, 4003, Rollback transaction
> > > OP_TX_CLOSE, 4004, Close transaction
> > >
> > > From the client side (java) new interfaces will be added:
> > >
> > > public interface ClientTransactions {
> > > public ClientTransaction txStart();
> > > public ClientTransaction txStart(TransactionConcurrency
> concurrency,
> > > TransactionIsolation isolation);
> > > public ClientTransaction txStart(TransactionConcurrency
> concurrency,
> > > TransactionIsolation isolation, long timeout, int txSize);
> > > public ClientTransaction tx(); // Get current connection
> transaction
> > > public ClientTransactions withLabel(String lb);
> > > }
> > >
> > > public interface ClientTransaction extends AutoCloseable {
> > > public IgniteUuid xid(); // Do we need it?
> > > public TransactionIsolation isolation();
> > > public TransactionConcurrency concurrency();
> > > public long timeout();
> > > public String label();
> > >
> > > public void commit();
> > > public void rollback();
> > > public void close();
> > > }
> > >
> > > From the server side, I think as a first step (while transactions
> > > suspend/resume is not fully implemented) we can use the same approach
> as
> > > for JDBC: add a new worker to each ClientRequestHandler and process
> > > requests by this worker if the transaction is started explicitly.
> > > ClientRequestHandler is bound to client connection, so there will be
> 1:1
> > > relation between client connection and thread, which process operations
> > in
> > > a transaction.
> > >
> > > Also, there is a couple of issues I want to discuss:
> > >
> > > We have overloaded method txStart with a different set of arguments.
> Some
> > > of the arguments may be missing. To pass arguments with OP_TX_START
> > > operation we have the next options:
> > >  * Serialize full set of arguments and use some value for missing
> > > arguments. For example -1 for int/long types and null for string type.
> We
> > > can't use 0 for int/long types since 0 it's a valid value for
> > concurrency,
> > > isolation and timeout arguments.
> > >  * Serialize arguments as a collection of property-value pairs (like
> it's
> > > implemented now for CacheConfiguration). In this case only explicitly
> > > provided arguments will be serialized.
> > > Which way is better? The simplest solution is to use the first option
> > and I
> > > want to use it if there were no objections.
> > >
> > > Do we need transaction id (xid) on the client side?
> > > If yes, we can pass xid along with OP_TX_COMMIT, OP_TX_ROLLBACK,
> > > OP_TX_CLOSE operations back to the server and do additional check on
> the
> > > server side (current transaction id for connection == transaction id
> > passed
> > > from client side). This, perhaps, will protect clients against some
> > errors
> > > (for example when client try to commit outdated transaction). But
> > > currently, we don't have data type IgniteUuid in thin client protocol.
> Do
> > > we need to add it too?
> > > Also, we can pass xid as a string just to inform the client and do not
> > pass
> > > it back to the server with commit/rollback operation.
> > > Or not to pass xid at all (.NET thick client works this way as far as I
> > > know).
> > >
> > > What do you think?
> > >
> > > ср, 7 мар. 

Re: Thin client: transactions support

[Nikolay Izhikov]

Hello, Alex.

We also have suspend and resume operations.
I think we should support them

вт, 26 марта 2019 г., 22:07 Sergey Kozlov :

> Hi
>
> Looks like I missed something but why we need OP_TX_CLOSE operation?
>
> Also I suggest to reserve a code for SAVEPOINT operation which very useful
> to understand where transaction has been rolled back
>
> On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov 
> wrote:
>
> > Hello Igniters!
> >
> > I want to pick up the ticket IGNITE-7369 and add transactions support to
> > our thin client implementation.
> > I've looked at our current implementation and have some proposals to
> > support transactions:
> >
> > Add new operations to thin client protocol:
> >
> > OP_TX_GET, 4000, Get current transaction for client connection
> > OP_TX_START, 4001, Start a new transaction
> > OP_TX_COMMIT, 4002, Commit transaction
> > OP_TX_ROLLBACK, 4003, Rollback transaction
> > OP_TX_CLOSE, 4004, Close transaction
> >
> > From the client side (java) new interfaces will be added:
> >
> > public interface ClientTransactions {
> > public ClientTransaction txStart();
> > public ClientTransaction txStart(TransactionConcurrency concurrency,
> > TransactionIsolation isolation);
> > public ClientTransaction txStart(TransactionConcurrency concurrency,
> > TransactionIsolation isolation, long timeout, int txSize);
> > public ClientTransaction tx(); // Get current connection transaction
> > public ClientTransactions withLabel(String lb);
> > }
> >
> > public interface ClientTransaction extends AutoCloseable {
> > public IgniteUuid xid(); // Do we need it?
> > public TransactionIsolation isolation();
> > public TransactionConcurrency concurrency();
> > public long timeout();
> > public String label();
> >
> > public void commit();
> > public void rollback();
> > public void close();
> > }
> >
> > From the server side, I think as a first step (while transactions
> > suspend/resume is not fully implemented) we can use the same approach as
> > for JDBC: add a new worker to each ClientRequestHandler and process
> > requests by this worker if the transaction is started explicitly.
> > ClientRequestHandler is bound to client connection, so there will be 1:1
> > relation between client connection and thread, which process operations
> in
> > a transaction.
> >
> > Also, there is a couple of issues I want to discuss:
> >
> > We have overloaded method txStart with a different set of arguments. Some
> > of the arguments may be missing. To pass arguments with OP_TX_START
> > operation we have the next options:
> >  * Serialize full set of arguments and use some value for missing
> > arguments. For example -1 for int/long types and null for string type. We
> > can't use 0 for int/long types since 0 it's a valid value for
> concurrency,
> > isolation and timeout arguments.
> >  * Serialize arguments as a collection of property-value pairs (like it's
> > implemented now for CacheConfiguration). In this case only explicitly
> > provided arguments will be serialized.
> > Which way is better? The simplest solution is to use the first option
> and I
> > want to use it if there were no objections.
> >
> > Do we need transaction id (xid) on the client side?
> > If yes, we can pass xid along with OP_TX_COMMIT, OP_TX_ROLLBACK,
> > OP_TX_CLOSE operations back to the server and do additional check on the
> > server side (current transaction id for connection == transaction id
> passed
> > from client side). This, perhaps, will protect clients against some
> errors
> > (for example when client try to commit outdated transaction). But
> > currently, we don't have data type IgniteUuid in thin client protocol. Do
> > we need to add it too?
> > Also, we can pass xid as a string just to inform the client and do not
> pass
> > it back to the server with commit/rollback operation.
> > Or not to pass xid at all (.NET thick client works this way as far as I
> > know).
> >
> > What do you think?
> >
> > ср, 7 мар. 2018 г. в 16:22, Vladimir Ozerov :
> >
> > > We already have transactions support in JDBC driver in TX SQL branch
> > > (ignite-4191). Currently it is implemented through separate thread,
> which
> > > is not that efficient. Ideally we need to finish decoupling
> transactions
> > > from threads. But alternatively we can change the logic on how we
> assign
> > > thread ID to specific transaction and "impersonate" thin client worker
> > > threads when serving requests from multiple users.
> > >
> > >
> > >
> > > On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda 
> wrote:
> > >
> > > > Here is an original discussion with a reference to the JIRA ticket:
> > > > http://apache-ignite-developers.2346864.n4.nabble.
> > > > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > > > Protocol-td25914.html
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >

Re: Thin client: transactions support

[Sergey Kozlov]

Hi

Looks like I missed something but why we need OP_TX_CLOSE operation?

Also I suggest to reserve a code for SAVEPOINT operation which very useful
to understand where transaction has been rolled back

On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov 
wrote:

> Hello Igniters!
>
> I want to pick up the ticket IGNITE-7369 and add transactions support to
> our thin client implementation.
> I've looked at our current implementation and have some proposals to
> support transactions:
>
> Add new operations to thin client protocol:
>
> OP_TX_GET, 4000, Get current transaction for client connection
> OP_TX_START, 4001, Start a new transaction
> OP_TX_COMMIT, 4002, Commit transaction
> OP_TX_ROLLBACK, 4003, Rollback transaction
> OP_TX_CLOSE, 4004, Close transaction
>
> From the client side (java) new interfaces will be added:
>
> public interface ClientTransactions {
> public ClientTransaction txStart();
> public ClientTransaction txStart(TransactionConcurrency concurrency,
> TransactionIsolation isolation);
> public ClientTransaction txStart(TransactionConcurrency concurrency,
> TransactionIsolation isolation, long timeout, int txSize);
> public ClientTransaction tx(); // Get current connection transaction
> public ClientTransactions withLabel(String lb);
> }
>
> public interface ClientTransaction extends AutoCloseable {
> public IgniteUuid xid(); // Do we need it?
> public TransactionIsolation isolation();
> public TransactionConcurrency concurrency();
> public long timeout();
> public String label();
>
> public void commit();
> public void rollback();
> public void close();
> }
>
> From the server side, I think as a first step (while transactions
> suspend/resume is not fully implemented) we can use the same approach as
> for JDBC: add a new worker to each ClientRequestHandler and process
> requests by this worker if the transaction is started explicitly.
> ClientRequestHandler is bound to client connection, so there will be 1:1
> relation between client connection and thread, which process operations in
> a transaction.
>
> Also, there is a couple of issues I want to discuss:
>
> We have overloaded method txStart with a different set of arguments. Some
> of the arguments may be missing. To pass arguments with OP_TX_START
> operation we have the next options:
>  * Serialize full set of arguments and use some value for missing
> arguments. For example -1 for int/long types and null for string type. We
> can't use 0 for int/long types since 0 it's a valid value for concurrency,
> isolation and timeout arguments.
>  * Serialize arguments as a collection of property-value pairs (like it's
> implemented now for CacheConfiguration). In this case only explicitly
> provided arguments will be serialized.
> Which way is better? The simplest solution is to use the first option and I
> want to use it if there were no objections.
>
> Do we need transaction id (xid) on the client side?
> If yes, we can pass xid along with OP_TX_COMMIT, OP_TX_ROLLBACK,
> OP_TX_CLOSE operations back to the server and do additional check on the
> server side (current transaction id for connection == transaction id passed
> from client side). This, perhaps, will protect clients against some errors
> (for example when client try to commit outdated transaction). But
> currently, we don't have data type IgniteUuid in thin client protocol. Do
> we need to add it too?
> Also, we can pass xid as a string just to inform the client and do not pass
> it back to the server with commit/rollback operation.
> Or not to pass xid at all (.NET thick client works this way as far as I
> know).
>
> What do you think?
>
> ср, 7 мар. 2018 г. в 16:22, Vladimir Ozerov :
>
> > We already have transactions support in JDBC driver in TX SQL branch
> > (ignite-4191). Currently it is implemented through separate thread, which
> > is not that efficient. Ideally we need to finish decoupling transactions
> > from threads. But alternatively we can change the logic on how we assign
> > thread ID to specific transaction and "impersonate" thin client worker
> > threads when serving requests from multiple users.
> >
> >
> >
> > On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda  wrote:
> >
> > > Here is an original discussion with a reference to the JIRA ticket:
> > > http://apache-ignite-developers.2346864.n4.nabble.
> > > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > > Protocol-td25914.html
> > >
> > > --
> > > Denis
> > >
> > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > > wrote:
> > >
> > > > Hi Dmitriy. I don't think we have a design proposal for transaction
> > > support
> > > > in thin clients. Do you mind taking this initiative and creating an
> IEP
> > > on
> > > > Wiki?
> > > >
> > > > D.
> > > >
> > > > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy Govorukhin <
> > > > dmitriy.govoruk...@gmail.com> wrote:
> > > >
> > > > > Hi, Igniters.
> > > > >
> > > 

Re: Thin client: transactions support

[Alex Plehanov]

Hello Igniters!

I want to pick up the ticket IGNITE-7369 and add transactions support to
our thin client implementation.
I've looked at our current implementation and have some proposals to
support transactions:

Add new operations to thin client protocol:

OP_TX_GET, 4000, Get current transaction for client connection
OP_TX_START, 4001, Start a new transaction
OP_TX_COMMIT, 4002, Commit transaction
OP_TX_ROLLBACK, 4003, Rollback transaction
OP_TX_CLOSE, 4004, Close transaction

>From the client side (java) new interfaces will be added:

public interface ClientTransactions {
public ClientTransaction txStart();
public ClientTransaction txStart(TransactionConcurrency concurrency,
TransactionIsolation isolation);
public ClientTransaction txStart(TransactionConcurrency concurrency,
TransactionIsolation isolation, long timeout, int txSize);
public ClientTransaction tx(); // Get current connection transaction
public ClientTransactions withLabel(String lb);
}

public interface ClientTransaction extends AutoCloseable {
public IgniteUuid xid(); // Do we need it?
public TransactionIsolation isolation();
public TransactionConcurrency concurrency();
public long timeout();
public String label();

public void commit();
public void rollback();
public void close();
}

>From the server side, I think as a first step (while transactions
suspend/resume is not fully implemented) we can use the same approach as
for JDBC: add a new worker to each ClientRequestHandler and process
requests by this worker if the transaction is started explicitly.
ClientRequestHandler is bound to client connection, so there will be 1:1
relation between client connection and thread, which process operations in
a transaction.

Also, there is a couple of issues I want to discuss:

We have overloaded method txStart with a different set of arguments. Some
of the arguments may be missing. To pass arguments with OP_TX_START
operation we have the next options:
 * Serialize full set of arguments and use some value for missing
arguments. For example -1 for int/long types and null for string type. We
can't use 0 for int/long types since 0 it's a valid value for concurrency,
isolation and timeout arguments.
 * Serialize arguments as a collection of property-value pairs (like it's
implemented now for CacheConfiguration). In this case only explicitly
provided arguments will be serialized.
Which way is better? The simplest solution is to use the first option and I
want to use it if there were no objections.

Do we need transaction id (xid) on the client side?
If yes, we can pass xid along with OP_TX_COMMIT, OP_TX_ROLLBACK,
OP_TX_CLOSE operations back to the server and do additional check on the
server side (current transaction id for connection == transaction id passed
from client side). This, perhaps, will protect clients against some errors
(for example when client try to commit outdated transaction). But
currently, we don't have data type IgniteUuid in thin client protocol. Do
we need to add it too?
Also, we can pass xid as a string just to inform the client and do not pass
it back to the server with commit/rollback operation.
Or not to pass xid at all (.NET thick client works this way as far as I
know).

What do you think?

ср, 7 мар. 2018 г. в 16:22, Vladimir Ozerov :

> We already have transactions support in JDBC driver in TX SQL branch
> (ignite-4191). Currently it is implemented through separate thread, which
> is not that efficient. Ideally we need to finish decoupling transactions
> from threads. But alternatively we can change the logic on how we assign
> thread ID to specific transaction and "impersonate" thin client worker
> threads when serving requests from multiple users.
>
>
>
> On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda  wrote:
>
> > Here is an original discussion with a reference to the JIRA ticket:
> > http://apache-ignite-developers.2346864.n4.nabble.
> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > Protocol-td25914.html
> >
> > --
> > Denis
> >
> > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy Setrakyan  >
> > wrote:
> >
> > > Hi Dmitriy. I don't think we have a design proposal for transaction
> > support
> > > in thin clients. Do you mind taking this initiative and creating an IEP
> > on
> > > Wiki?
> > >
> > > D.
> > >
> > > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy Govorukhin <
> > > dmitriy.govoruk...@gmail.com> wrote:
> > >
> > > > Hi, Igniters.
> > > >
> > > > I've seen a lot of discussions about thin client and binary protocol,
> > > but I
> > > > did not hear anything about transactions support. Do we have some
> draft
> > > for
> > > > this purpose?
> > > >
> > > > As I understand we have several problems:
> > > >
> > > >- thread and transaction have hard related (we use thread-local
> > > variable
> > > >and thread name)
> > > >- we can process only one transaction at the same time in one
> thread
> > > (it
> > > >mean we need 

Re: Thin client: transactions support

[Vladimir Ozerov]

We already have transactions support in JDBC driver in TX SQL branch
(ignite-4191). Currently it is implemented through separate thread, which
is not that efficient. Ideally we need to finish decoupling transactions
from threads. But alternatively we can change the logic on how we assign
thread ID to specific transaction and "impersonate" thin client worker
threads when serving requests from multiple users.



On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda  wrote:

> Here is an original discussion with a reference to the JIRA ticket:
> http://apache-ignite-developers.2346864.n4.nabble.
> com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> Protocol-td25914.html
>
> --
> Denis
>
> On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy Setrakyan 
> wrote:
>
> > Hi Dmitriy. I don't think we have a design proposal for transaction
> support
> > in thin clients. Do you mind taking this initiative and creating an IEP
> on
> > Wiki?
> >
> > D.
> >
> > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy Govorukhin <
> > dmitriy.govoruk...@gmail.com> wrote:
> >
> > > Hi, Igniters.
> > >
> > > I've seen a lot of discussions about thin client and binary protocol,
> > but I
> > > did not hear anything about transactions support. Do we have some draft
> > for
> > > this purpose?
> > >
> > > As I understand we have several problems:
> > >
> > >- thread and transaction have hard related (we use thread-local
> > variable
> > >and thread name)
> > >- we can process only one transaction at the same time in one thread
> > (it
> > >mean we need hold thread per client. If connect 100 thin clients to
> 1
> > >server node, then need to hold 100 thread on the server side)
> > >
> > > Let's discuss how we can implement transactions for the thin client.
> > >
> >
>

Re: Thin client: transactions support

[Denis Magda]

Here is an original discussion with a reference to the JIRA ticket:
http://apache-ignite-developers.2346864.n4.nabble.com/Re-Transaction-operations-using-the-Ignite-Thin-Client-Protocol-td25914.html

--
Denis

On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy Setrakyan 
wrote:

> Hi Dmitriy. I don't think we have a design proposal for transaction support
> in thin clients. Do you mind taking this initiative and creating an IEP on
> Wiki?
>
> D.
>
> On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy Govorukhin <
> dmitriy.govoruk...@gmail.com> wrote:
>
> > Hi, Igniters.
> >
> > I've seen a lot of discussions about thin client and binary protocol,
> but I
> > did not hear anything about transactions support. Do we have some draft
> for
> > this purpose?
> >
> > As I understand we have several problems:
> >
> >- thread and transaction have hard related (we use thread-local
> variable
> >and thread name)
> >- we can process only one transaction at the same time in one thread
> (it
> >mean we need hold thread per client. If connect 100 thin clients to 1
> >server node, then need to hold 100 thread on the server side)
> >
> > Let's discuss how we can implement transactions for the thin client.
> >
>

Re: Thin client: transactions support

[Dmitriy Setrakyan]

Hi Dmitriy. I don't think we have a design proposal for transaction support
in thin clients. Do you mind taking this initiative and creating an IEP on
Wiki?

D.

On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:

> Hi, Igniters.
>
> I've seen a lot of discussions about thin client and binary protocol, but I
> did not hear anything about transactions support. Do we have some draft for
> this purpose?
>
> As I understand we have several problems:
>
>- thread and transaction have hard related (we use thread-local variable
>and thread name)
>- we can process only one transaction at the same time in one thread (it
>mean we need hold thread per client. If connect 100 thin clients to 1
>server node, then need to hold 100 thread on the server side)
>
> Let's discuss how we can implement transactions for the thin client.
>

Thin client: transactions support

[Dmitriy Govorukhin]

Hi, Igniters.

I've seen a lot of discussions about thin client and binary protocol, but I
did not hear anything about transactions support. Do we have some draft for
this purpose?

As I understand we have several problems:

   - thread and transaction have hard related (we use thread-local variable
   and thread name)
   - we can process only one transaction at the same time in one thread (it
   mean we need hold thread per client. If connect 100 thin clients to 1
   server node, then need to hold 100 thread on the server side)

Let's discuss how we can implement transactions for the thin client.