You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Dmitriy Govorukhin <dm...@gmail.com> on 2018/03/06 16:46:28 UTC
Thin client: transactions support
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
Posted by Pavel Tupitsyn <pt...@apache.org>.
I think it is less confusing than ThinClientConfiguration.
On Fri, Aug 23, 2019 at 8:49 PM Alex Plehanov <pl...@gmail.com>
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 <pt...@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
Posted by Pavel Tupitsyn <pt...@apache.org>.
Alex, thank you, I'm convinced now, no objections
to ThinClientConfiguration.
On Wed, Aug 28, 2019 at 12:59 PM Alex Plehanov <pl...@gmail.com>
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 <pt...@apache.org>:
>
> > 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 <pl...@gmail.com>
> > 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.kasnacheev@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 <is...@apache.org>:
> > > >
> > > > > 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.kasnacheev@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 <is...@apache.org>:
> > > > > >
> > > > > > > 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.kasnacheev@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.kasnacheev@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.alex@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 <
> > > > ptupitsyn@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
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pt...@apache.org>:
> 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 <pl...@gmail.com>
> 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.kasnacheev@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 <is...@apache.org>:
> > >
> > > > 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.kasnacheev@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 <is...@apache.org>:
> > > > >
> > > > > > 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.kasnacheev@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.kasnacheev@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.alex@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 <
> > > ptupitsyn@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
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <pl...@gmail.com>
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 <il...@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 <is...@apache.org>:
> >
> > > 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.kasnacheev@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 <is...@apache.org>:
> > > >
> > > > > 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.kasnacheev@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.kasnacheev@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.alex@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 <
> > ptupitsyn@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
Posted by Alex Plehanov <pl...@gmail.com>.
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 <il...@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 <is...@apache.org>:
>
> > 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.kasnacheev@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 <is...@apache.org>:
> > >
> > > > 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.kasnacheev@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.kasnacheev@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.alex@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 <
> ptupitsyn@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
Posted by Ilya Kasnacheev <il...@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 <is...@apache.org>:
> 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.kasnacheev@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 <is...@apache.org>:
> >
> > > 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.kasnacheev@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.kasnacheev@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.alex@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 <ptupitsyn@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
Posted by Igor Sapego <is...@apache.org>.
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 <il...@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 <is...@apache.org>:
>
> > 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.kasnacheev@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.kasnacheev@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.alex@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 <pt...@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
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <is...@apache.org>:
> 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.kasnacheev@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.kasnacheev@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 <pl...@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 <pt...@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
Posted by Igor Sapego <is...@apache.org>.
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 <il...@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 <il...@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 <pl...@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 <pt...@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
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <il...@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 <pl...@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 <pt...@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
Posted by Ilya Kasnacheev <il...@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 <pl...@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 <pt...@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
Posted by Alex Plehanov <pl...@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 <pt...@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
Posted by Pavel Tupitsyn <pt...@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
Posted by Alex Plehanov <pl...@gmail.com>.
Igor,
Make sense. I've fixed the implementation according to your proposal.
ср, 21 авг. 2019 г. в 17:59, Igor Sapego <is...@apache.org>:
> 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 <pl...@gmail.com>
> 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 <pt...@apache.org>:
> >
> > > 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.alex@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, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > > 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.alex@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.alex@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
> > > > thread
> > > > > > > successfully) and complete a future of its own request or
> another
> > > > > threads
> > > > > > > request.
> > > > > > >
> > > > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vololo100@gmail.com
> >:
> > > > > > >
> > > > > > >> 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.alex@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 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, Павлухин Иван <
> > vololo100@gmail.com
> > > >:
> > > > > > >> >
> > > > > > >> > > 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.alex@gmail.com>:
> > > > > > >> > > >
> > > > > > >> > > > 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 <
> > > > > plehanov.alex@gmail.com>:
> > > > > > >> > > >
> > > > > > >> > > > > 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, Павлухин Иван <
> > > > > vololo100@gmail.com>:
> > > > > > >> > > > >
> > > > > > >> > > > >> 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.alex@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 <
> > > > > isapego@apache.org>:
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > > 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 Павлухин Иван <
> > > > > > >> > > vololo100@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 = <isolation> -- per SQL
> > > > client
> > > > > > >> session
> > > > > > >> > > > >> > > > (usually physical network connection)
> > > > > > >> > > > >> > > > set global tx_isolation = <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 <
> > > > > > >> isapego@apache.org>:
> > > > > > >> > > > >> > > > >
> > > > > > >> > > > >> > > > > 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.alex@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 <
> > > > > > >> isapego@apache.org
> > > > > > >> > > >:
> > > > > > >> > > > >> > > > > >
> > > > > > >> > > > >> > > > > > > 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.alex@gmail.com>
> > > > > > >> > > > >> > > > > > > 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, Павлухин
> Иван
> > <
> > > > > > >> > > > >> vololo100@gmail.com>:
> > > > > > >> > > > >> > > > > > > >
> > > > > > >> > > > >> > > > > > > > > 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
> > > > <
> > > > > > >> > > > >> > > > plehanov.alex@gmail.com
> > > > > > >> > > > >> > > > > > >:
> > > > > > >> > > > >> > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > 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 <
> > > > > > >> > > > >> > > > plehanov.alex@gmail.com
> > > > > > >> > > > >> > > > > > >:
> > > > > > >> > > > >> > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > > Vladimir,
> > > > > > >> > > > >> > > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in
> the
> > > near
> > > > > > >> future.
> > > > > > >> > > > >> > > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14,
> > Vladimir
> > > > > Ozerov <
> > > > > > >> > > > >> > > > > > vozerov@gridgain.com
> > > > > > >> > > > >> > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > >> 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 <
> > > > > > >> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> > > > > > >> > > > >> > > > > > > > > > >> 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
> > > > > > >> <
> > > > > > >> > > > >> > > > > > > > plehanov.alex@gmail.com
> > > > > > >> > > > >> > > > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> >
> > > > > > >> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > > > > > >> > > 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 <
> > > > > > >> > > > >> > > > > > > > ptupitsyn@apache.org
> > > > > > >> > > > >> > > > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >>
> > > > > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > > > > > >> > > > >> > > > > > > > > > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > > > > >> > > > >> <
> > > > > > >> > > > >> > > > > > > > > dpavlov@apache.org
> > > > > > >> > > > >> > > > > > > > > > >> >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > > > > >> > > > >> > > > > > > > > > >> > >> >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > > > >> > > > >> > > <
> > > > > > >> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > > > >> > > > >> > > > > > > > <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> vozerov@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.alex@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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > nizhikov@apache.org
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> Hello,
> > > > Alex.
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We
> > also
> > > > have
> > > > > > >> suspend
> > > > > > >> > > and
> > > > > > >> > > > >> > > resume
> > > > > > >> > > > >> > > > > > > > > operations.
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I
> > think
> > > we
> > > > > > >> should
> > > > > > >> > > > >> support them
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт,
> 26
> > > > марта
> > > > > > >> 2019 г.,
> > > > > > >> > > > >> 22:07
> > > > > > >> > > > >> > > > Sergey
> > > > > > >> > > > >> > > > > > > > Kozlov
> > > > > > >> > > > >> > > > > > > > > <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > skozlov@gridgain.com
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > > >> > > > >> > > > > > > > > > >> > >> &
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > --
> > > > > > >> > > Best regards,
> > > > > > >> > > Ivan Pavlukhin
> > > > > > >> > >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Best regards,
> > > > > > >> Ivan Pavlukhin
> > > > > > >>
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Igor Sapego <is...@apache.org>.
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 <pl...@gmail.com>
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 <pt...@apache.org>:
>
> > 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 <pl...@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, Павлухин Иван <vo...@gmail.com>:
> > >
> > > > 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.alex@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.alex@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
> > > thread
> > > > > > successfully) and complete a future of its own request or another
> > > > threads
> > > > > > request.
> > > > > >
> > > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
> > > > > >
> > > > > >> 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.alex@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 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, Павлухин Иван <
> vololo100@gmail.com
> > >:
> > > > > >> >
> > > > > >> > > 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.alex@gmail.com>:
> > > > > >> > > >
> > > > > >> > > > 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 <
> > > > plehanov.alex@gmail.com>:
> > > > > >> > > >
> > > > > >> > > > > 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, Павлухин Иван <
> > > > vololo100@gmail.com>:
> > > > > >> > > > >
> > > > > >> > > > >> 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.alex@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 <
> > > > isapego@apache.org>:
> > > > > >> > > > >> >
> > > > > >> > > > >> > > 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 Павлухин Иван <
> > > > > >> > > vololo100@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 = <isolation> -- per SQL
> > > client
> > > > > >> session
> > > > > >> > > > >> > > > (usually physical network connection)
> > > > > >> > > > >> > > > set global tx_isolation = <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 <
> > > > > >> isapego@apache.org>:
> > > > > >> > > > >> > > > >
> > > > > >> > > > >> > > > > 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.alex@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 <
> > > > > >> isapego@apache.org
> > > > > >> > > >:
> > > > > >> > > > >> > > > > >
> > > > > >> > > > >> > > > > > > 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.alex@gmail.com>
> > > > > >> > > > >> > > > > > > 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, Павлухин Иван
> <
> > > > > >> > > > >> vololo100@gmail.com>:
> > > > > >> > > > >> > > > > > > >
> > > > > >> > > > >> > > > > > > > > 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
> > > <
> > > > > >> > > > >> > > > plehanov.alex@gmail.com
> > > > > >> > > > >> > > > > > >:
> > > > > >> > > > >> > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > 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 <
> > > > > >> > > > >> > > > plehanov.alex@gmail.com
> > > > > >> > > > >> > > > > > >:
> > > > > >> > > > >> > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > > Vladimir,
> > > > > >> > > > >> > > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the
> > near
> > > > > >> future.
> > > > > >> > > > >> > > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14,
> Vladimir
> > > > Ozerov <
> > > > > >> > > > >> > > > > > vozerov@gridgain.com
> > > > > >> > > > >> > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > >> 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 <
> > > > > >> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> > > > > >> > > > >> > > > > > > > > > >> 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
> > > > > >> <
> > > > > >> > > > >> > > > > > > > plehanov.alex@gmail.com
> > > > > >> > > > >> > > > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> >
> > > > > >> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > > > > >> > > 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 <
> > > > > >> > > > >> > > > > > > > ptupitsyn@apache.org
> > > > > >> > > > >> > > > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >>
> > > > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > > >> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > > > > >> > > > >> > > > > > > > > > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > > > >> > > > >> <
> > > > > >> > > > >> > > > > > > > > dpavlov@apache.org
> > > > > >> > > > >> > > > > > > > > > >> >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > > > >> > > > >> > > > > > > > > > >> > >> >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > > >> > > > >> > > <
> > > > > >> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > > >> > > > >> > > > > > > > <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> nizhikov@apache.org
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello,
> > > Alex.
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We
> also
> > > have
> > > > > >> suspend
> > > > > >> > > and
> > > > > >> > > > >> > > resume
> > > > > >> > > > >> > > > > > > > > operations.
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I
> think
> > we
> > > > > >> should
> > > > > >> > > > >> support them
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26
> > > марта
> > > > > >> 2019 г.,
> > > > > >> > > > >> 22:07
> > > > > >> > > > >> > > > Sergey
> > > > > >> > > > >> > > > > > > > Kozlov
> > > > > >> > > > >> > > > > > > > > <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> skozlov@gridgain.com
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > >> > > > >> > > > > > > > > > >> > >> &
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > --
> > > > > >> > > Best regards,
> > > > > >> > > Ivan Pavlukhin
> > > > > >> > >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Best regards,
> > > > > >> Ivan Pavlukhin
> > > > > >>
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pt...@apache.org>:
> 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 <pl...@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, Павлухин Иван <vo...@gmail.com>:
> >
> > > 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 <pl...@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 <pl...@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
> > thread
> > > > > successfully) and complete a future of its own request or another
> > > threads
> > > > > request.
> > > > >
> > > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > >> 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.alex@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 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, Павлухин Иван <vololo100@gmail.com
> >:
> > > > >> >
> > > > >> > > 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.alex@gmail.com>:
> > > > >> > > >
> > > > >> > > > 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 <
> > > plehanov.alex@gmail.com>:
> > > > >> > > >
> > > > >> > > > > 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, Павлухин Иван <
> > > vololo100@gmail.com>:
> > > > >> > > > >
> > > > >> > > > >> 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.alex@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 <
> > > isapego@apache.org>:
> > > > >> > > > >> >
> > > > >> > > > >> > > 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 Павлухин Иван <
> > > > >> > > vololo100@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 = <isolation> -- per SQL
> > client
> > > > >> session
> > > > >> > > > >> > > > (usually physical network connection)
> > > > >> > > > >> > > > set global tx_isolation = <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 <
> > > > >> isapego@apache.org>:
> > > > >> > > > >> > > > >
> > > > >> > > > >> > > > > 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.alex@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 <
> > > > >> isapego@apache.org
> > > > >> > > >:
> > > > >> > > > >> > > > > >
> > > > >> > > > >> > > > > > > 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.alex@gmail.com>
> > > > >> > > > >> > > > > > > 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, Павлухин Иван <
> > > > >> > > > >> vololo100@gmail.com>:
> > > > >> > > > >> > > > > > > >
> > > > >> > > > >> > > > > > > > > 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
> > <
> > > > >> > > > >> > > > plehanov.alex@gmail.com
> > > > >> > > > >> > > > > > >:
> > > > >> > > > >> > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > 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 <
> > > > >> > > > >> > > > plehanov.alex@gmail.com
> > > > >> > > > >> > > > > > >:
> > > > >> > > > >> > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > > Vladimir,
> > > > >> > > > >> > > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the
> near
> > > > >> future.
> > > > >> > > > >> > > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir
> > > Ozerov <
> > > > >> > > > >> > > > > > vozerov@gridgain.com
> > > > >> > > > >> > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > >> 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 <
> > > > >> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> > > > >> > > > >> > > > > > > > > > >> 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
> > > > >> <
> > > > >> > > > >> > > > > > > > plehanov.alex@gmail.com
> > > > >> > > > >> > > > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> >
> > > > >> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > > > >> > > 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 <
> > > > >> > > > >> > > > > > > > ptupitsyn@apache.org
> > > > >> > > > >> > > > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >>
> > > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > >> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > > > >> > > > >> > > > > > > > > > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > > >> > > > >> <
> > > > >> > > > >> > > > > > > > > dpavlov@apache.org
> > > > >> > > > >> > > > > > > > > > >> >:
> > > > >> > > > >> > > > > > > > > > >> > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > > >> > > > >> > > > > > > > > > >> > >> >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > >> > > > >> > > <
> > > > >> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > >> > > > >> > > > > > > > <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello,
> > Alex.
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also
> > have
> > > > >> suspend
> > > > >> > > and
> > > > >> > > > >> > > resume
> > > > >> > > > >> > > > > > > > > operations.
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think
> we
> > > > >> should
> > > > >> > > > >> support them
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26
> > марта
> > > > >> 2019 г.,
> > > > >> > > > >> 22:07
> > > > >> > > > >> > > > Sergey
> > > > >> > > > >> > > > > > > > Kozlov
> > > > >> > > > >> > > > > > > > > <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > >> > > > >> > > > > > > > > > >> > >> &
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > --
> > > > >> > > Best regards,
> > > > >> > > Ivan Pavlukhin
> > > > >> > >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Best regards,
> > > > >> Ivan Pavlukhin
> > > > >>
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <pl...@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, Павлухин Иван <vo...@gmail.com>:
>
> > 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 <pl...@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 <pl...@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
> thread
> > > > successfully) and complete a future of its own request or another
> > threads
> > > > request.
> > > >
> > > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > >> 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.alex@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 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, Павлухин Иван <vo...@gmail.com>:
> > > >> >
> > > >> > > 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.alex@gmail.com>:
> > > >> > > >
> > > >> > > > 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 <
> > plehanov.alex@gmail.com>:
> > > >> > > >
> > > >> > > > > 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, Павлухин Иван <
> > vololo100@gmail.com>:
> > > >> > > > >
> > > >> > > > >> 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.alex@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 <
> > isapego@apache.org>:
> > > >> > > > >> >
> > > >> > > > >> > > 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 Павлухин Иван <
> > > >> > > vololo100@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 = <isolation> -- per SQL
> client
> > > >> session
> > > >> > > > >> > > > (usually physical network connection)
> > > >> > > > >> > > > set global tx_isolation = <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 <
> > > >> isapego@apache.org>:
> > > >> > > > >> > > > >
> > > >> > > > >> > > > > 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.alex@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 <
> > > >> isapego@apache.org
> > > >> > > >:
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > > 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.alex@gmail.com>
> > > >> > > > >> > > > > > > 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, Павлухин Иван <
> > > >> > > > >> vololo100@gmail.com>:
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > > > 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
> <
> > > >> > > > >> > > > plehanov.alex@gmail.com
> > > >> > > > >> > > > > > >:
> > > >> > > > >> > > > > > > > > >
> > > >> > > > >> > > > > > > > > > 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 <
> > > >> > > > >> > > > plehanov.alex@gmail.com
> > > >> > > > >> > > > > > >:
> > > >> > > > >> > > > > > > > > >
> > > >> > > > >> > > > > > > > > > > Vladimir,
> > > >> > > > >> > > > > > > > > > >
> > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> > > >> future.
> > > >> > > > >> > > > > > > > > > >
> > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir
> > Ozerov <
> > > >> > > > >> > > > > > vozerov@gridgain.com
> > > >> > > > >> > > > > > > >:
> > > >> > > > >> > > > > > > > > > >
> > > >> > > > >> > > > > > > > > > >> 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 <
> > > >> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> > > >> > > > >> > > > > > > > > > >> 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
> > > >> <
> > > >> > > > >> > > > > > > > plehanov.alex@gmail.com
> > > >> > > > >> > > > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> >
> > > >> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > > >> > > 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 <
> > > >> > > > >> > > > > > > > ptupitsyn@apache.org
> > > >> > > > >> > > > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >>
> > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > >> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > > >> > > > >> > > > > > > > > > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > >> > > > >> <
> > > >> > > > >> > > > > > > > > dpavlov@apache.org
> > > >> > > > >> > > > > > > > > > >> >:
> > > >> > > > >> > > > > > > > > > >> > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > >> > > > >> > > > > > > > > > >> > >> >:
> > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > >> > > > >> > > <
> > > >> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > >> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > >> > > > >> > > > > > > > <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello,
> Alex.
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also
> have
> > > >> suspend
> > > >> > > and
> > > >> > > > >> > > resume
> > > >> > > > >> > > > > > > > > operations.
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
> > > >> should
> > > >> > > > >> support them
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26
> марта
> > > >> 2019 г.,
> > > >> > > > >> 22:07
> > > >> > > > >> > > > Sergey
> > > >> > > > >> > > > > > > > Kozlov
> > > >> > > > >> > > > > > > > > <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > >> > > > >> > > > > > > > > > >> > >> &
> > > >> > > > >
> > > >> > > > >
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > --
> > > >> > > Best regards,
> > > >> > > Ivan Pavlukhin
> > > >> > >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Ivan Pavlukhin
> > > >>
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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, Павлухин Иван <vo...@gmail.com>:
> 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 <pl...@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 <pl...@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 thread
> > > successfully) and complete a future of its own request or another
> threads
> > > request.
> > >
> > > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
> > >
> > >> 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 <pl...@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 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, Павлухин Иван <vo...@gmail.com>:
> > >> >
> > >> > > 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.alex@gmail.com>:
> > >> > > >
> > >> > > > 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 <
> plehanov.alex@gmail.com>:
> > >> > > >
> > >> > > > > 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, Павлухин Иван <
> vololo100@gmail.com>:
> > >> > > > >
> > >> > > > >> 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.alex@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 <
> isapego@apache.org>:
> > >> > > > >> >
> > >> > > > >> > > 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 Павлухин Иван <
> > >> > > vololo100@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 = <isolation> -- per SQL client
> > >> session
> > >> > > > >> > > > (usually physical network connection)
> > >> > > > >> > > > set global tx_isolation = <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 <
> > >> isapego@apache.org>:
> > >> > > > >> > > > >
> > >> > > > >> > > > > 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.alex@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 <
> > >> isapego@apache.org
> > >> > > >:
> > >> > > > >> > > > > >
> > >> > > > >> > > > > > > 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.alex@gmail.com>
> > >> > > > >> > > > > > > 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, Павлухин Иван <
> > >> > > > >> vololo100@gmail.com>:
> > >> > > > >> > > > > > > >
> > >> > > > >> > > > > > > > > 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 <
> > >> > > > >> > > > plehanov.alex@gmail.com
> > >> > > > >> > > > > > >:
> > >> > > > >> > > > > > > > > >
> > >> > > > >> > > > > > > > > > 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 <
> > >> > > > >> > > > plehanov.alex@gmail.com
> > >> > > > >> > > > > > >:
> > >> > > > >> > > > > > > > > >
> > >> > > > >> > > > > > > > > > > Vladimir,
> > >> > > > >> > > > > > > > > > >
> > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> > >> future.
> > >> > > > >> > > > > > > > > > >
> > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir
> Ozerov <
> > >> > > > >> > > > > > vozerov@gridgain.com
> > >> > > > >> > > > > > > >:
> > >> > > > >> > > > > > > > > > >
> > >> > > > >> > > > > > > > > > >> 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 <
> > >> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> > >> > > > >> > > > > > > > > > >> 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
> > >> <
> > >> > > > >> > > > > > > > plehanov.alex@gmail.com
> > >> > > > >> > > > > > > > > >:
> > >> > > > >> > > > > > > > > > >> >
> > >> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > >> > > 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 <
> > >> > > > >> > > > > > > > ptupitsyn@apache.org
> > >> > > > >> > > > > > > > > >:
> > >> > > > >> > > > > > > > > > >> > >>
> > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > >> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > >> > > > >> > > > > > > > > > >> > >
> > >> > > > >> > > > > > > > > > >> > >> > 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
> > >> > > > >> <
> > >> > > > >> > > > > > > > > dpavlov@apache.org
> > >> > > > >> > > > > > > > > > >> >:
> > >> > > > >> > > > > > > > > > >> > >> > >
> > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > >> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > >> > > > >> > > > > > > > > > >> > >> >:
> > >> > > > >> > > > > > > > > > >> > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > >> > > > >> > > <
> > >> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > >> > > > >> > > > > > > > > > >> > >> > > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > >> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > >> > > > >> > > > > > > > > > >> > >> > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > >> > > > >> > > > > > > > <
> > >> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
> > >> suspend
> > >> > > and
> > >> > > > >> > > resume
> > >> > > > >> > > > > > > > > operations.
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
> > >> should
> > >> > > > >> support them
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
> > >> 2019 г.,
> > >> > > > >> 22:07
> > >> > > > >> > > > Sergey
> > >> > > > >> > > > > > > > Kozlov
> > >> > > > >> > > > > > > > > <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > >> > > > >> > > > > > > > > > >> > >> &
> > >> > > > >
> > >> > > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Best regards,
> > >> > > Ivan Pavlukhin
> > >> > >
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >> Ivan Pavlukhin
> > >>
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
>
Re: Thin client: transactions support
Posted by Павлухин Иван <vo...@gmail.com>.
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 <pl...@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 <pl...@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 thread
> > successfully) and complete a future of its own request or another threads
> > request.
> >
> > пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
> >
> >> 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 <pl...@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 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, Павлухин Иван <vo...@gmail.com>:
> >> >
> >> > > 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 <pl...@gmail.com>:
> >> > > >
> >> > > > 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 <pl...@gmail.com>:
> >> > > >
> >> > > > > 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, Павлухин Иван <vo...@gmail.com>:
> >> > > > >
> >> > > > >> 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.alex@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 <is...@apache.org>:
> >> > > > >> >
> >> > > > >> > > 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 Павлухин Иван <
> >> > > vololo100@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 = <isolation> -- per SQL client
> >> session
> >> > > > >> > > > (usually physical network connection)
> >> > > > >> > > > set global tx_isolation = <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 <
> >> isapego@apache.org>:
> >> > > > >> > > > >
> >> > > > >> > > > > 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.alex@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 <
> >> isapego@apache.org
> >> > > >:
> >> > > > >> > > > > >
> >> > > > >> > > > > > > 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.alex@gmail.com>
> >> > > > >> > > > > > > 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, Павлухин Иван <
> >> > > > >> vololo100@gmail.com>:
> >> > > > >> > > > > > > >
> >> > > > >> > > > > > > > > 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 <
> >> > > > >> > > > plehanov.alex@gmail.com
> >> > > > >> > > > > > >:
> >> > > > >> > > > > > > > > >
> >> > > > >> > > > > > > > > > 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 <
> >> > > > >> > > > plehanov.alex@gmail.com
> >> > > > >> > > > > > >:
> >> > > > >> > > > > > > > > >
> >> > > > >> > > > > > > > > > > Vladimir,
> >> > > > >> > > > > > > > > > >
> >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> >> future.
> >> > > > >> > > > > > > > > > >
> >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> >> > > > >> > > > > > vozerov@gridgain.com
> >> > > > >> > > > > > > >:
> >> > > > >> > > > > > > > > > >
> >> > > > >> > > > > > > > > > >> 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 <
> >> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> >> > > > >> > > > > > > > > > >> 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
> >> <
> >> > > > >> > > > > > > > plehanov.alex@gmail.com
> >> > > > >> > > > > > > > > >:
> >> > > > >> > > > > > > > > > >> >
> >> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> >> > > 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 <
> >> > > > >> > > > > > > > ptupitsyn@apache.org
> >> > > > >> > > > > > > > > >:
> >> > > > >> > > > > > > > > > >> > >>
> >> > > > >> > > > > > > > > > >> > >> > 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 <
> >> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> >> > > > >> > > > > > > > > > >> > >
> >> > > > >> > > > > > > > > > >> > >> > 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
> >> > > > >> <
> >> > > > >> > > > > > > > > dpavlov@apache.org
> >> > > > >> > > > > > > > > > >> >:
> >> > > > >> > > > > > > > > > >> > >> > >
> >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> >> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> >> > > > >> > > > > > > > > > >> > >> >:
> >> > > > >> > > > > > > > > > >> > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > 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
> >> > > > >> > > <
> >> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> >> > > > >> > > > > > > > > > >> > >> > > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> >> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> >> > > > >> > > > > > > > > > >> > >> > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> >> > > > >> > > > > > > > <
> >> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> >> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> >> > > > >> > > > > > > > > > >> > >> > > > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> >> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
> >> suspend
> >> > > and
> >> > > > >> > > resume
> >> > > > >> > > > > > > > > operations.
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
> >> should
> >> > > > >> support them
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
> >> 2019 г.,
> >> > > > >> 22:07
> >> > > > >> > > > Sergey
> >> > > > >> > > > > > > > Kozlov
> >> > > > >> > > > > > > > > <
> >> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> >> > > > >> > > > > > > > > > >> > >> &
> >> > > > >
> >> > > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Best regards,
> >> > > Ivan Pavlukhin
> >> > >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Ivan Pavlukhin
> >>
> >
--
Best regards,
Ivan Pavlukhin
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@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 <pl...@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 thread
> successfully) and complete a future of its own request or another threads
> request.
>
> пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
>
>> 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 <pl...@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 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, Павлухин Иван <vo...@gmail.com>:
>> >
>> > > 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 <pl...@gmail.com>:
>> > > >
>> > > > 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 <pl...@gmail.com>:
>> > > >
>> > > > > 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, Павлухин Иван <vo...@gmail.com>:
>> > > > >
>> > > > >> 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.alex@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 <is...@apache.org>:
>> > > > >> >
>> > > > >> > > 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 Павлухин Иван <
>> > > vololo100@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 = <isolation> -- per SQL client
>> session
>> > > > >> > > > (usually physical network connection)
>> > > > >> > > > set global tx_isolation = <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 <
>> isapego@apache.org>:
>> > > > >> > > > >
>> > > > >> > > > > 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.alex@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 <
>> isapego@apache.org
>> > > >:
>> > > > >> > > > > >
>> > > > >> > > > > > > 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.alex@gmail.com>
>> > > > >> > > > > > > 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, Павлухин Иван <
>> > > > >> vololo100@gmail.com>:
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > > 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 <
>> > > > >> > > > plehanov.alex@gmail.com
>> > > > >> > > > > > >:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > 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 <
>> > > > >> > > > plehanov.alex@gmail.com
>> > > > >> > > > > > >:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > > Vladimir,
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
>> future.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
>> > > > >> > > > > > vozerov@gridgain.com
>> > > > >> > > > > > > >:
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > >> 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 <
>> > > > >> > > > > > > > > plehanov.alex@gmail.com>
>> > > > >> > > > > > > > > > >> 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
>> <
>> > > > >> > > > > > > > plehanov.alex@gmail.com
>> > > > >> > > > > > > > > >:
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
>> > > 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 <
>> > > > >> > > > > > > > ptupitsyn@apache.org
>> > > > >> > > > > > > > > >:
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> > 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 <
>> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > 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
>> > > > >> <
>> > > > >> > > > > > > > > dpavlov@apache.org
>> > > > >> > > > > > > > > > >> >:
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > 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 <
>> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >> >:
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > 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
>> > > > >> > > <
>> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
>> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
>> > > > >> > > > > > > > <
>> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
>> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
>> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
>> > > > >> > > > > > > > > > >> > >> > > > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
>> suspend
>> > > and
>> > > > >> > > resume
>> > > > >> > > > > > > > > operations.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
>> should
>> > > > >> support them
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
>> 2019 г.,
>> > > > >> 22:07
>> > > > >> > > > Sergey
>> > > > >> > > > > > > > Kozlov
>> > > > >> > > > > > > > > <
>> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
>> > > > >> > > > > > > > > > >> > >> &
>> > > > >
>> > > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > > Ivan Pavlukhin
>> > >
>>
>>
>>
>> --
>> Best regards,
>> Ivan Pavlukhin
>>
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@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 thread
successfully) and complete a future of its own request or another threads
request.
пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vo...@gmail.com>:
> 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 <pl...@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 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, Павлухин Иван <vo...@gmail.com>:
> >
> > > 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 <pl...@gmail.com>:
> > > >
> > > > 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 <pl...@gmail.com>:
> > > >
> > > > > 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, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > >> 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.alex@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 <is...@apache.org>:
> > > > >> >
> > > > >> > > 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 Павлухин Иван <
> > > vololo100@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 = <isolation> -- per SQL client
> session
> > > > >> > > > (usually physical network connection)
> > > > >> > > > set global tx_isolation = <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 <isapego@apache.org
> >:
> > > > >> > > > >
> > > > >> > > > > 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.alex@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 <
> isapego@apache.org
> > > >:
> > > > >> > > > > >
> > > > >> > > > > > > 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.alex@gmail.com>
> > > > >> > > > > > > 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, Павлухин Иван <
> > > > >> vololo100@gmail.com>:
> > > > >> > > > > > > >
> > > > >> > > > > > > > > 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 <
> > > > >> > > > plehanov.alex@gmail.com
> > > > >> > > > > > >:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > 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 <
> > > > >> > > > plehanov.alex@gmail.com
> > > > >> > > > > > >:
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > > > > Vladimir,
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> future.
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > > > >> > > > > > vozerov@gridgain.com
> > > > >> > > > > > > >:
> > > > >> > > > > > > > > > >
> > > > >> > > > > > > > > > >> 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 <
> > > > >> > > > > > > > > plehanov.alex@gmail.com>
> > > > >> > > > > > > > > > >> 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 <
> > > > >> > > > > > > > plehanov.alex@gmail.com
> > > > >> > > > > > > > > >:
> > > > >> > > > > > > > > > >> >
> > > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > > 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 <
> > > > >> > > > > > > > ptupitsyn@apache.org
> > > > >> > > > > > > > > >:
> > > > >> > > > > > > > > > >> > >>
> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > > > >> > > > > > > > > > >> > >
> > > > >> > > > > > > > > > >> > >> > 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
> > > > >> <
> > > > >> > > > > > > > > dpavlov@apache.org
> > > > >> > > > > > > > > > >> >:
> > > > >> > > > > > > > > > >> > >> > >
> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > > >> > > > > > > > > > >> > >> >:
> > > > >> > > > > > > > > > >> > >> > > >
> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > >> > > <
> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > >> > > > > > > > > > >> > >> > > > >
> > > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > > >> > > > > > > > > > >> > >> > > >:
> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > >> > > > > > > > <
> > > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
> suspend
> > > and
> > > > >> > > resume
> > > > >> > > > > > > > > operations.
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we should
> > > > >> support them
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
> 2019 г.,
> > > > >> 22:07
> > > > >> > > > Sergey
> > > > >> > > > > > > > Kozlov
> > > > >> > > > > > > > > <
> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > >> > > > > > > > > > >> > >> &
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: Thin client: transactions support
Posted by Павлухин Иван <vo...@gmail.com>.
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 <pl...@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 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, Павлухин Иван <vo...@gmail.com>:
>
> > 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 <pl...@gmail.com>:
> > >
> > > 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 <pl...@gmail.com>:
> > >
> > > > 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, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > >> Alex,
> > > >>
> > > >> Are you going to introduce settings specifying default values for tx
> > > >> concurrency and isolation in client configuration?
> > > >>
> > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <pl...@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 <is...@apache.org>:
> > > >> >
> > > >> > > 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 Павлухин Иван <
> > vololo100@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 = <isolation> -- per SQL client session
> > > >> > > > (usually physical network connection)
> > > >> > > > set global tx_isolation = <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 <is...@apache.org>:
> > > >> > > > >
> > > >> > > > > 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.alex@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 <isapego@apache.org
> > >:
> > > >> > > > > >
> > > >> > > > > > > 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.alex@gmail.com>
> > > >> > > > > > > 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, Павлухин Иван <
> > > >> vololo100@gmail.com>:
> > > >> > > > > > > >
> > > >> > > > > > > > > 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 <
> > > >> > > > plehanov.alex@gmail.com
> > > >> > > > > > >:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > 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 <
> > > >> > > > plehanov.alex@gmail.com
> > > >> > > > > > >:
> > > >> > > > > > > > > >
> > > >> > > > > > > > > > > Vladimir,
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near future.
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > > >> > > > > > vozerov@gridgain.com
> > > >> > > > > > > >:
> > > >> > > > > > > > > > >
> > > >> > > > > > > > > > >> 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 <
> > > >> > > > > > > > > plehanov.alex@gmail.com>
> > > >> > > > > > > > > > >> 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 <
> > > >> > > > > > > > plehanov.alex@gmail.com
> > > >> > > > > > > > > >:
> > > >> > > > > > > > > > >> >
> > > >> > > > > > > > > > >> > > 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.kasnacheev@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
> > 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 <
> > > >> > > > > > > > ptupitsyn@apache.org
> > > >> > > > > > > > > >:
> > > >> > > > > > > > > > >> > >>
> > > >> > > > > > > > > > >> > >> > 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 <
> > > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > > >> > > > > > > > > > >> > >
> > > >> > > > > > > > > > >> > >> > 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
> > > >> <
> > > >> > > > > > > > > dpavlov@apache.org
> > > >> > > > > > > > > > >> >:
> > > >> > > > > > > > > > >> > >> > >
> > > >> > > > > > > > > > >> > >> > > > 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 <
> > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > >> > > > > > > > > > >> > >> >:
> > > >> > > > > > > > > > >> > >> > > >
> > > >> > > > > > > > > > >> > >> > > > > 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
> > > >> > > <
> > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > >> > > > > > > > > > >> > >> > > > >
> > > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > >> > > > > > > > > > >> > >> > > >:
> > > >> > > > > > > > > > >> > >> > > > > > >
> > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > >> > > > > > > > <
> > > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > >> > > > > > > > > > >> > >> > > > > >:
> > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend
> > and
> > > >> > > resume
> > > >> > > > > > > > > operations.
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we should
> > > >> support them
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г.,
> > > >> 22:07
> > > >> > > > Sergey
> > > >> > > > > > > > Kozlov
> > > >> > > > > > > > > <
> > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > >> > > > > > > > > > >> > >> &
> > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
--
Best regards,
Ivan Pavlukhin
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@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 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, Павлухин Иван <vo...@gmail.com>:
> 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 <pl...@gmail.com>:
> >
> > 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 <pl...@gmail.com>:
> >
> > > 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, Павлухин Иван <vo...@gmail.com>:
> > >
> > >> Alex,
> > >>
> > >> Are you going to introduce settings specifying default values for tx
> > >> concurrency and isolation in client configuration?
> > >>
> > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <pl...@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 <is...@apache.org>:
> > >> >
> > >> > > 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 Павлухин Иван <
> vololo100@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 = <isolation> -- per SQL client session
> > >> > > > (usually physical network connection)
> > >> > > > set global tx_isolation = <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 <is...@apache.org>:
> > >> > > > >
> > >> > > > > 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.alex@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 <isapego@apache.org
> >:
> > >> > > > > >
> > >> > > > > > > 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.alex@gmail.com>
> > >> > > > > > > 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, Павлухин Иван <
> > >> vololo100@gmail.com>:
> > >> > > > > > > >
> > >> > > > > > > > > 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 <
> > >> > > > plehanov.alex@gmail.com
> > >> > > > > > >:
> > >> > > > > > > > > >
> > >> > > > > > > > > > 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 <
> > >> > > > plehanov.alex@gmail.com
> > >> > > > > > >:
> > >> > > > > > > > > >
> > >> > > > > > > > > > > Vladimir,
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near future.
> > >> > > > > > > > > > >
> > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > >> > > > > > vozerov@gridgain.com
> > >> > > > > > > >:
> > >> > > > > > > > > > >
> > >> > > > > > > > > > >> 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 <
> > >> > > > > > > > > plehanov.alex@gmail.com>
> > >> > > > > > > > > > >> 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 <
> > >> > > > > > > > plehanov.alex@gmail.com
> > >> > > > > > > > > >:
> > >> > > > > > > > > > >> >
> > >> > > > > > > > > > >> > > 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.kasnacheev@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
> 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 <
> > >> > > > > > > > ptupitsyn@apache.org
> > >> > > > > > > > > >:
> > >> > > > > > > > > > >> > >>
> > >> > > > > > > > > > >> > >> > 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 <
> > >> > > > > > > > > > >> plehanov.alex@gmail.com
> > >> > > > > > > > > > >> > >
> > >> > > > > > > > > > >> > >> > 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
> > >> <
> > >> > > > > > > > > dpavlov@apache.org
> > >> > > > > > > > > > >> >:
> > >> > > > > > > > > > >> > >> > >
> > >> > > > > > > > > > >> > >> > > > 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 <
> > >> > > > > > > > > > >> > plehanov.alex@gmail.com
> > >> > > > > > > > > > >> > >> >:
> > >> > > > > > > > > > >> > >> > > >
> > >> > > > > > > > > > >> > >> > > > > 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
> > >> > > <
> > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > >> > > > > > > > > > >> > >> > > > >
> > >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > >> > > > > > > > > > >> > >> > > >:
> > >> > > > > > > > > > >> > >> > > > > > >
> > >> > > > > > > > > > >> > >> > > > > > > > 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
> > >> > > > > > > > <
> > >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > >> > > > > > > > > > >> > >> > > > > >:
> > >> > > > > > > > > > >> > >> > > > > > > > >>
> > >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > >> > > > > > > > > > >> > >> > > > > > > >:
> > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend
> and
> > >> > > resume
> > >> > > > > > > > > operations.
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we should
> > >> support them
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г.,
> > >> 22:07
> > >> > > > Sergey
> > >> > > > > > > > Kozlov
> > >> > > > > > > > > <
> > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > >> > > > > > > > > > >> > >> > > > > > > >:
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > >> > > > > > > > > > >> > >> &
> > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: Thin client: transactions support
Posted by Павлухин Иван <vo...@gmail.com>.
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 <pl...@gmail.com>:
>
> 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 <pl...@gmail.com>:
>
> > 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, Павлухин Иван <vo...@gmail.com>:
> >
> >> Alex,
> >>
> >> Are you going to introduce settings specifying default values for tx
> >> concurrency and isolation in client configuration?
> >>
> >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <pl...@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 <is...@apache.org>:
> >> >
> >> > > 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 Павлухин Иван <vo...@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 = <isolation> -- per SQL client session
> >> > > > (usually physical network connection)
> >> > > > set global tx_isolation = <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 <is...@apache.org>:
> >> > > > >
> >> > > > > 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.alex@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 <is...@apache.org>:
> >> > > > > >
> >> > > > > > > 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.alex@gmail.com>
> >> > > > > > > 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, Павлухин Иван <
> >> vololo100@gmail.com>:
> >> > > > > > > >
> >> > > > > > > > > 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 <
> >> > > > plehanov.alex@gmail.com
> >> > > > > > >:
> >> > > > > > > > > >
> >> > > > > > > > > > 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 <
> >> > > > plehanov.alex@gmail.com
> >> > > > > > >:
> >> > > > > > > > > >
> >> > > > > > > > > > > Vladimir,
> >> > > > > > > > > > >
> >> > > > > > > > > > > Ok, then I will rewrite IEP in the near future.
> >> > > > > > > > > > >
> >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> >> > > > > > vozerov@gridgain.com
> >> > > > > > > >:
> >> > > > > > > > > > >
> >> > > > > > > > > > >> 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 <
> >> > > > > > > > > plehanov.alex@gmail.com>
> >> > > > > > > > > > >> 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 <
> >> > > > > > > > plehanov.alex@gmail.com
> >> > > > > > > > > >:
> >> > > > > > > > > > >> >
> >> > > > > > > > > > >> > > 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.kasnacheev@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 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 <
> >> > > > > > > > ptupitsyn@apache.org
> >> > > > > > > > > >:
> >> > > > > > > > > > >> > >>
> >> > > > > > > > > > >> > >> > 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 <
> >> > > > > > > > > > >> plehanov.alex@gmail.com
> >> > > > > > > > > > >> > >
> >> > > > > > > > > > >> > >> > 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
> >> <
> >> > > > > > > > > dpavlov@apache.org
> >> > > > > > > > > > >> >:
> >> > > > > > > > > > >> > >> > >
> >> > > > > > > > > > >> > >> > > > 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 <
> >> > > > > > > > > > >> > plehanov.alex@gmail.com
> >> > > > > > > > > > >> > >> >:
> >> > > > > > > > > > >> > >> > > >
> >> > > > > > > > > > >> > >> > > > > 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
> >> > > <
> >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> >> > > > > > > > > > >> > >> > > > >
> >> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> >> > > > > > > > > > >> > >> > vozerov@gridgain.com
> >> > > > > > > > > > >> > >> > > >:
> >> > > > > > > > > > >> > >> > > > > > >
> >> > > > > > > > > > >> > >> > > > > > > > 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
> >> > > > > > > > <
> >> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> >> > > > > > > > > > >> > >> > > > > >:
> >> > > > > > > > > > >> > >> > > > > > > > >>
> >> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> >> > > > > > > > > > >> > >> > > > > > > >:
> >> > > > > > > > > > >> > >> > > > > > > > >> > >
> >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend and
> >> > > resume
> >> > > > > > > > > operations.
> >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we should
> >> support them
> >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г.,
> >> 22:07
> >> > > > Sergey
> >> > > > > > > > Kozlov
> >> > > > > > > > > <
> >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> >> > > > > > > > > > >> > >> > > > > > > >:
> >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> >> > > > > > > > > > >> > >> &
> >
> >
--
Best regards,
Ivan Pavlukhin
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pl...@gmail.com>:
> 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, Павлухин Иван <vo...@gmail.com>:
>
>> Alex,
>>
>> Are you going to introduce settings specifying default values for tx
>> concurrency and isolation in client configuration?
>>
>> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <pl...@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 <is...@apache.org>:
>> >
>> > > 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 Павлухин Иван <vo...@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 = <isolation> -- per SQL client session
>> > > > (usually physical network connection)
>> > > > set global tx_isolation = <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 <is...@apache.org>:
>> > > > >
>> > > > > 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.alex@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 <is...@apache.org>:
>> > > > > >
>> > > > > > > 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.alex@gmail.com>
>> > > > > > > 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, Павлухин Иван <
>> vololo100@gmail.com>:
>> > > > > > > >
>> > > > > > > > > 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 <
>> > > > plehanov.alex@gmail.com
>> > > > > > >:
>> > > > > > > > > >
>> > > > > > > > > > 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 <
>> > > > plehanov.alex@gmail.com
>> > > > > > >:
>> > > > > > > > > >
>> > > > > > > > > > > Vladimir,
>> > > > > > > > > > >
>> > > > > > > > > > > Ok, then I will rewrite IEP in the near future.
>> > > > > > > > > > >
>> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
>> > > > > > vozerov@gridgain.com
>> > > > > > > >:
>> > > > > > > > > > >
>> > > > > > > > > > >> 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 <
>> > > > > > > > > plehanov.alex@gmail.com>
>> > > > > > > > > > >> 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 <
>> > > > > > > > plehanov.alex@gmail.com
>> > > > > > > > > >:
>> > > > > > > > > > >> >
>> > > > > > > > > > >> > > 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.kasnacheev@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 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 <
>> > > > > > > > ptupitsyn@apache.org
>> > > > > > > > > >:
>> > > > > > > > > > >> > >>
>> > > > > > > > > > >> > >> > 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 <
>> > > > > > > > > > >> plehanov.alex@gmail.com
>> > > > > > > > > > >> > >
>> > > > > > > > > > >> > >> > 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
>> <
>> > > > > > > > > dpavlov@apache.org
>> > > > > > > > > > >> >:
>> > > > > > > > > > >> > >> > >
>> > > > > > > > > > >> > >> > > > 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 <
>> > > > > > > > > > >> > plehanov.alex@gmail.com
>> > > > > > > > > > >> > >> >:
>> > > > > > > > > > >> > >> > > >
>> > > > > > > > > > >> > >> > > > > 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
>> > > <
>> > > > > > > > > > >> > >> vozerov@gridgain.com>:
>> > > > > > > > > > >> > >> > > > >
>> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
>> > > > > > > > > > >> > >> > vozerov@gridgain.com
>> > > > > > > > > > >> > >> > > >:
>> > > > > > > > > > >> > >> > > > > > >
>> > > > > > > > > > >> > >> > > > > > > > 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
>> > > > > > > > <
>> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
>> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
>> > > > > > > > > > >> > >> > > > > >:
>> > > > > > > > > > >> > >> > > > > > > > >>
>> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
>> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
>> > > > > > > > > > >> > >> > > > > > > >:
>> > > > > > > > > > >> > >> > > > > > > > >> > >
>> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
>> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend and
>> > > resume
>> > > > > > > > > operations.
>> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we should
>> support them
>> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г.,
>> 22:07
>> > > > Sergey
>> > > > > > > > Kozlov
>> > > > > > > > > <
>> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
>> > > > > > > > > > >> > >> > > > > > > >:
>> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
>> > > > > > > > > > >> > >> &
>
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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, Павлухин Иван <vo...@gmail.com>:
> Alex,
>
> Are you going to introduce settings specifying default values for tx
> concurrency and isolation in client configuration?
>
> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <pl...@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 <is...@apache.org>:
> >
> > > 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 Павлухин Иван <vo...@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 = <isolation> -- per SQL client session
> > > > (usually physical network connection)
> > > > set global tx_isolation = <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 <is...@apache.org>:
> > > > >
> > > > > 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.alex@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 <is...@apache.org>:
> > > > > >
> > > > > > > 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.alex@gmail.com>
> > > > > > > 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, Павлухин Иван <
> vololo100@gmail.com>:
> > > > > > > >
> > > > > > > > > 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 <
> > > > plehanov.alex@gmail.com
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > > 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 <
> > > > plehanov.alex@gmail.com
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Vladimir,
> > > > > > > > > > >
> > > > > > > > > > > Ok, then I will rewrite IEP in the near future.
> > > > > > > > > > >
> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > > > > > vozerov@gridgain.com
> > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > >> 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 <
> > > > > > > > > plehanov.alex@gmail.com>
> > > > > > > > > > >> 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 <
> > > > > > > > plehanov.alex@gmail.com
> > > > > > > > > >:
> > > > > > > > > > >> >
> > > > > > > > > > >> > > 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.kasnacheev@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 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 <
> > > > > > > > ptupitsyn@apache.org
> > > > > > > > > >:
> > > > > > > > > > >> > >>
> > > > > > > > > > >> > >> > 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 <
> > > > > > > > > > >> plehanov.alex@gmail.com
> > > > > > > > > > >> > >
> > > > > > > > > > >> > >> > 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 <
> > > > > > > > > dpavlov@apache.org
> > > > > > > > > > >> >:
> > > > > > > > > > >> > >> > >
> > > > > > > > > > >> > >> > > > 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
> <
> > > > > > > > > > >> > plehanov.alex@gmail.com
> > > > > > > > > > >> > >> >:
> > > > > > > > > > >> > >> > > >
> > > > > > > > > > >> > >> > > > > 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
> > > <
> > > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > > > > > > > >> > >> > > > >
> > > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > > > > > > >> > >> > vozerov@gridgain.com
> > > > > > > > > > >> > >> > > >:
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > > 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
> > > > > > > > <
> > > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > > > > > > >> > >> > > > > >:
> > > > > > > > > > >> > >> > > > > > > > >>
> > > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend and
> > > resume
> > > > > > > > > operations.
> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we should support
> them
> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г.,
> 22:07
> > > > Sergey
> > > > > > > > Kozlov
> > > > > > > > > <
> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > > > > > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > > > > > > > >> > >> > > > > > > > >> > >:
> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > > > > > > > >> > >> <
> > > > > > > > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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
> > > > > > > > > > >> > >> > > > <
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > > > --
> > > > > > > > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > > > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > > > > > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > > > >> > >> > > > > > > > >> > --
> > > > > > > > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > > > > > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > > > > > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > > > >> > >> > > > > > > > >>
> > > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > > >> > >> > > > > > >
> > > > > > > > > > >> > >> > > > > >
> > > > > > > > > > >> > >> > > > >
> > > > > > > > > > >> > >> > > >
> > > > > > > > > > >> > >> > >
> > > > > > > > > > >> > >> >
> > > > > > > > > > >> > >>
> > > > > > > > > > >> > >
> > > > > > > > > > >> >
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best regards,
> > > > > > > > > Ivan Pavlukhin
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: Thin client: transactions support
Posted by Павлухин Иван <vo...@gmail.com>.
Alex,
Are you going to introduce settings specifying default values for tx
concurrency and isolation in client configuration?
пн, 20 мая 2019 г. в 19:34, Alex Plehanov <pl...@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 <is...@apache.org>:
>
> > 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 Павлухин Иван <vo...@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 = <isolation> -- per SQL client session
> > > (usually physical network connection)
> > > set global tx_isolation = <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 <is...@apache.org>:
> > > >
> > > > 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.alex@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 <is...@apache.org>:
> > > > >
> > > > > > 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.alex@gmail.com>
> > > > > > 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, Павлухин Иван <vo...@gmail.com>:
> > > > > > >
> > > > > > > > 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 <
> > > plehanov.alex@gmail.com
> > > > > >:
> > > > > > > > >
> > > > > > > > > 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 <
> > > plehanov.alex@gmail.com
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Vladimir,
> > > > > > > > > >
> > > > > > > > > > Ok, then I will rewrite IEP in the near future.
> > > > > > > > > >
> > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > > > > vozerov@gridgain.com
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > >> 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 <
> > > > > > > > plehanov.alex@gmail.com>
> > > > > > > > > >> 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 <
> > > > > > > plehanov.alex@gmail.com
> > > > > > > > >:
> > > > > > > > > >> >
> > > > > > > > > >> > > 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.kasnacheev@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 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 <
> > > > > > > ptupitsyn@apache.org
> > > > > > > > >:
> > > > > > > > > >> > >>
> > > > > > > > > >> > >> > 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 <
> > > > > > > > > >> plehanov.alex@gmail.com
> > > > > > > > > >> > >
> > > > > > > > > >> > >> > 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 <
> > > > > > > > dpavlov@apache.org
> > > > > > > > > >> >:
> > > > > > > > > >> > >> > >
> > > > > > > > > >> > >> > > > 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 <
> > > > > > > > > >> > plehanov.alex@gmail.com
> > > > > > > > > >> > >> >:
> > > > > > > > > >> > >> > > >
> > > > > > > > > >> > >> > > > > 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
> > <
> > > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > > > > > > >> > >> > > > >
> > > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > > > > > >> > >> > vozerov@gridgain.com
> > > > > > > > > >> > >> > > >:
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > > 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
> > > > > > > <
> > > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > > > > > >> > >> > > > > >:
> > > > > > > > > >> > >> > > > > > > > >>
> > > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > > > > > > >> > >> > > > > > > >:
> > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend and
> > resume
> > > > > > > > operations.
> > > > > > > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07
> > > Sergey
> > > > > > > Kozlov
> > > > > > > > <
> > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > > > > > > >> > >> > > > > > > >:
> > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > > > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > > > > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > > > > > > >> > >> > > > > > > > >> > >:
> > > > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > > > > > > >> > >> <
> > > > > > > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > > > > > > >> > >> > > > > > > > >> > > > > 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
> > > > > > > > > >> > >> > > > <
> > > > > > > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > > > --
> > > > > > > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > > > > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > > >> > >> > > > > > > > >> > --
> > > > > > > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > > > > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > > > > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > > >> > >> > > > > > > > >>
> > > > > > > > > >> > >> > > > > > > > >
> > > > > > > > > >> > >> > > > > > > >
> > > > > > > > > >> > >> > > > > > >
> > > > > > > > > >> > >> > > > > >
> > > > > > > > > >> > >> > > > >
> > > > > > > > > >> > >> > > >
> > > > > > > > > >> > >> > >
> > > > > > > > > >> > >> >
> > > > > > > > > >> > >>
> > > > > > > > > >> > >
> > > > > > > > > >> >
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > > Ivan Pavlukhin
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
--
Best regards,
Ivan Pavlukhin
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@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 <is...@apache.org>:
> 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 Павлухин Иван <vo...@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 = <isolation> -- per SQL client session
> > (usually physical network connection)
> > set global tx_isolation = <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 <is...@apache.org>:
> > >
> > > 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.alex@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 <is...@apache.org>:
> > > >
> > > > > 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.alex@gmail.com>
> > > > > 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, Павлухин Иван <vo...@gmail.com>:
> > > > > >
> > > > > > > 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 <
> > plehanov.alex@gmail.com
> > > > >:
> > > > > > > >
> > > > > > > > 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 <
> > plehanov.alex@gmail.com
> > > > >:
> > > > > > > >
> > > > > > > > > Vladimir,
> > > > > > > > >
> > > > > > > > > Ok, then I will rewrite IEP in the near future.
> > > > > > > > >
> > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > > > vozerov@gridgain.com
> > > > > >:
> > > > > > > > >
> > > > > > > > >> 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 <
> > > > > > > plehanov.alex@gmail.com>
> > > > > > > > >> 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 <
> > > > > > plehanov.alex@gmail.com
> > > > > > > >:
> > > > > > > > >> >
> > > > > > > > >> > > 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.kasnacheev@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 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 <
> > > > > > ptupitsyn@apache.org
> > > > > > > >:
> > > > > > > > >> > >>
> > > > > > > > >> > >> > 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 <
> > > > > > > > >> plehanov.alex@gmail.com
> > > > > > > > >> > >
> > > > > > > > >> > >> > 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 <
> > > > > > > dpavlov@apache.org
> > > > > > > > >> >:
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> > > > 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 <
> > > > > > > > >> > plehanov.alex@gmail.com
> > > > > > > > >> > >> >:
> > > > > > > > >> > >> > > >
> > > > > > > > >> > >> > > > > 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
> <
> > > > > > > > >> > >> vozerov@gridgain.com>:
> > > > > > > > >> > >> > > > >
> > > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > > > > >> > >> > vozerov@gridgain.com
> > > > > > > > >> > >> > > >:
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > > > > 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
> > > > > > <
> > > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > > > > >> > >> > > > > >:
> > > > > > > > >> > >> > > > > > > > >>
> > > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > > > > > >> > >> > > > > > > >:
> > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > >> > >> > > > > > > > >> > > > We also have suspend and
> resume
> > > > > > > operations.
> > > > > > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07
> > Sergey
> > > > > > Kozlov
> > > > > > > <
> > > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > > > > > >> > >> > > > > > > >:
> > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > > > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > > > > > >> > >> > > > > > > > >> > >:
> > > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > > > > > >> > >> <
> > > > > > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > > > > > >> > >> > > > > > > > >> > > > > 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
> > > > > > > > >> > >> > > > <
> > > > > > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > >> > >> > > > > > > > >> > > > > --
> > > > > > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > > > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > >> > >> > > > > > > > >> > --
> > > > > > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > > > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > > > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > > > > > >> > >> > > > > > > > >> >
> > > > > > > > >> > >> > > > > > > > >>
> > > > > > > > >> > >> > > > > > > > >
> > > > > > > > >> > >> > > > > > > >
> > > > > > > > >> > >> > > > > > >
> > > > > > > > >> > >> > > > > >
> > > > > > > > >> > >> > > > >
> > > > > > > > >> > >> > > >
> > > > > > > > >> > >> > >
> > > > > > > > >> > >> >
> > > > > > > > >> > >>
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best regards,
> > > > > > > Ivan Pavlukhin
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>
Re: Thin client: transactions support
Posted by Igor Sapego <is...@apache.org>.
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 Павлухин Иван <vo...@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 = <isolation> -- per SQL client session
> (usually physical network connection)
> set global tx_isolation = <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 <is...@apache.org>:
> >
> > 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 <pl...@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 <is...@apache.org>:
> > >
> > > > 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.alex@gmail.com>
> > > > 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, Павлухин Иван <vo...@gmail.com>:
> > > > >
> > > > > > 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 <
> plehanov.alex@gmail.com
> > > >:
> > > > > > >
> > > > > > > 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 <
> plehanov.alex@gmail.com
> > > >:
> > > > > > >
> > > > > > > > Vladimir,
> > > > > > > >
> > > > > > > > Ok, then I will rewrite IEP in the near future.
> > > > > > > >
> > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > > vozerov@gridgain.com
> > > > >:
> > > > > > > >
> > > > > > > >> 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 <
> > > > > > plehanov.alex@gmail.com>
> > > > > > > >> 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 <
> > > > > plehanov.alex@gmail.com
> > > > > > >:
> > > > > > > >> >
> > > > > > > >> > > 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.kasnacheev@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 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 <
> > > > > ptupitsyn@apache.org
> > > > > > >:
> > > > > > > >> > >>
> > > > > > > >> > >> > 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 <
> > > > > > > >> plehanov.alex@gmail.com
> > > > > > > >> > >
> > > > > > > >> > >> > 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 <
> > > > > > dpavlov@apache.org
> > > > > > > >> >:
> > > > > > > >> > >> > >
> > > > > > > >> > >> > > > 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 <
> > > > > > > >> > plehanov.alex@gmail.com
> > > > > > > >> > >> >:
> > > > > > > >> > >> > > >
> > > > > > > >> > >> > > > > 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 <
> > > > > > > >> > >> vozerov@gridgain.com>:
> > > > > > > >> > >> > > > >
> > > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > > > >> > >> > vozerov@gridgain.com
> > > > > > > >> > >> > > >:
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > > > > 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
> > > > > <
> > > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > > > >> > >> > > > > >:
> > > > > > > >> > >> > > > > > > > >>
> > > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > > > > >> > >> > > > > > > >:
> > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > > > > > operations.
> > > > > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07
> Sergey
> > > > > Kozlov
> > > > > > <
> > > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > > > > >> > >> > > > > > > >:
> > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > > > > >> > >> > > > > > > > >> > >:
> > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > > > > >> > >> <
> > > > > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > > > > >> > >> > > > > > > > >> > > > > 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
> > > > > > > >> > >> > > > <
> > > > > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > > > > >> > >> > > > > > > > >> > > > > > > >
> > > > > > > >> > >> > > > > > > > >> > > > > > >
> > > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > >> > >> > > > > > > > >> > > > > --
> > > > > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > > >> > >> > > > > > > > >> > >
> > > > > > > >> > >> > > > > > > > >> >
> > > > > > > >> > >> > > > > > > > >> >
> > > > > > > >> > >> > > > > > > > >> > --
> > > > > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > > > > >> > >> > > > > > > > >> >
> > > > > > > >> > >> > > > > > > > >>
> > > > > > > >> > >> > > > > > > > >
> > > > > > > >> > >> > > > > > > >
> > > > > > > >> > >> > > > > > >
> > > > > > > >> > >> > > > > >
> > > > > > > >> > >> > > > >
> > > > > > > >> > >> > > >
> > > > > > > >> > >> > >
> > > > > > > >> > >> >
> > > > > > > >> > >>
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Ivan Pavlukhin
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
Re: Thin client: transactions support
Posted by Павлухин Иван <vo...@gmail.com>.
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 = <isolation> -- per SQL client session
(usually physical network connection)
set global tx_isolation = <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 <is...@apache.org>:
>
> 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 <pl...@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 <is...@apache.org>:
> >
> > > 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 <pl...@gmail.com>
> > > 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, Павлухин Иван <vo...@gmail.com>:
> > > >
> > > > > 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 <plehanov.alex@gmail.com
> > >:
> > > > > >
> > > > > > 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 <plehanov.alex@gmail.com
> > >:
> > > > > >
> > > > > > > Vladimir,
> > > > > > >
> > > > > > > Ok, then I will rewrite IEP in the near future.
> > > > > > >
> > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> > vozerov@gridgain.com
> > > >:
> > > > > > >
> > > > > > >> 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 <
> > > > > plehanov.alex@gmail.com>
> > > > > > >> 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 <
> > > > plehanov.alex@gmail.com
> > > > > >:
> > > > > > >> >
> > > > > > >> > > 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.kasnacheev@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 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 <
> > > > ptupitsyn@apache.org
> > > > > >:
> > > > > > >> > >>
> > > > > > >> > >> > 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 <
> > > > > > >> plehanov.alex@gmail.com
> > > > > > >> > >
> > > > > > >> > >> > 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 <
> > > > > dpavlov@apache.org
> > > > > > >> >:
> > > > > > >> > >> > >
> > > > > > >> > >> > > > 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 <
> > > > > > >> > plehanov.alex@gmail.com
> > > > > > >> > >> >:
> > > > > > >> > >> > > >
> > > > > > >> > >> > > > > 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 <
> > > > > > >> > >> vozerov@gridgain.com>:
> > > > > > >> > >> > > > >
> > > > > > >> > >> > > > > > 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.alex@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 <
> > > > > > >> > >> > vozerov@gridgain.com
> > > > > > >> > >> > > >:
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > > > > 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
> > > > <
> > > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > > >> > >> > > > skozlov@gridgain.com
> > > > > > >> > >> > > > > >:
> > > > > > >> > >> > > > > > > > >>
> > > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > > >> > >> > > > > > nizhikov@apache.org
> > > > > > >> > >> > > > > > > >:
> > > > > > >> > >> > > > > > > > >> > >
> > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > > > > operations.
> > > > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey
> > > > Kozlov
> > > > > <
> > > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > > > >> > >> > > > > > > >:
> > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > > > >> > >> > > > > > > > >> > >:
> > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > > > >> > >> <
> > > > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > > > >> > >> > > > > > > > >> > > > > 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
> > > > > > >> > >> > > > <
> > > > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > > > >> > >> > > > > > > > >> > > > > > > >
> > > > > > >> > >> > > > > > > > >> > > > > > >
> > > > > > >> > >> > > > > > > > >> > > > > >
> > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > >> > >> > > > > > > > >> > > > > --
> > > > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > > > >> > >> > > > > > > > >> > > > >
> > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > >> > > > > > > > >> > >
> > > > > > >> > >> > > > > > > > >> >
> > > > > > >> > >> > > > > > > > >> >
> > > > > > >> > >> > > > > > > > >> > --
> > > > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > > > >> > >> > > > > > > > >> >
> > > > > > >> > >> > > > > > > > >>
> > > > > > >> > >> > > > > > > > >
> > > > > > >> > >> > > > > > > >
> > > > > > >> > >> > > > > > >
> > > > > > >> > >> > > > > >
> > > > > > >> > >> > > > >
> > > > > > >> > >> > > >
> > > > > > >> > >> > >
> > > > > > >> > >> >
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Ivan Pavlukhin
> > > > >
> > > > >
> > > >
> > >
> >
--
Best regards,
Ivan Pavlukhin
Re: Thin client: transactions support
Posted by Igor Sapego <is...@apache.org>.
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 <pl...@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 <is...@apache.org>:
>
> > 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 <pl...@gmail.com>
> > 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, Павлухин Иван <vo...@gmail.com>:
> > >
> > > > 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 <plehanov.alex@gmail.com
> >:
> > > > >
> > > > > 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 <plehanov.alex@gmail.com
> >:
> > > > >
> > > > > > Vladimir,
> > > > > >
> > > > > > Ok, then I will rewrite IEP in the near future.
> > > > > >
> > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> vozerov@gridgain.com
> > >:
> > > > > >
> > > > > >> 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 <
> > > > plehanov.alex@gmail.com>
> > > > > >> 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 <
> > > plehanov.alex@gmail.com
> > > > >:
> > > > > >> >
> > > > > >> > > 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.kasnacheev@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 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 <
> > > ptupitsyn@apache.org
> > > > >:
> > > > > >> > >>
> > > > > >> > >> > 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 <
> > > > > >> plehanov.alex@gmail.com
> > > > > >> > >
> > > > > >> > >> > 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 <
> > > > dpavlov@apache.org
> > > > > >> >:
> > > > > >> > >> > >
> > > > > >> > >> > > > 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 <
> > > > > >> > plehanov.alex@gmail.com
> > > > > >> > >> >:
> > > > > >> > >> > > >
> > > > > >> > >> > > > > 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 <
> > > > > >> > >> vozerov@gridgain.com>:
> > > > > >> > >> > > > >
> > > > > >> > >> > > > > > 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.alex@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 <
> > > > > >> > >> > vozerov@gridgain.com
> > > > > >> > >> > > >:
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > > > > 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
> > > <
> > > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > > >> > >> > > > skozlov@gridgain.com
> > > > > >> > >> > > > > >:
> > > > > >> > >> > > > > > > > >>
> > > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > > >> > >> > > > > > nizhikov@apache.org
> > > > > >> > >> > > > > > > >:
> > > > > >> > >> > > > > > > > >> > >
> > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > > > operations.
> > > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey
> > > Kozlov
> > > > <
> > > > > >> > >> > > > > > skozlov@gridgain.com
> > > > > >> > >> > > > > > > >:
> > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > > >> > >> > > > > > > > >> > >:
> > > > > >> > >> > > > > > > > >> > > > > >
> > > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > > >> > >> <
> > > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > > >> > >> > > > > > > > >> > > > > 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
> > > > > >> > >> > > > <
> > > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > > >> > >> > > > > > > > >> > > > > > > >
> > > > > >> > >> > > > > > > > >> > > > > > >
> > > > > >> > >> > > > > > > > >> > > > > >
> > > > > >> > >> > > > > > > > >> > > > >
> > > > > >> > >> > > > > > > > >> > > > >
> > > > > >> > >> > > > > > > > >> > > > > --
> > > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > > >> > >> > > > > > > > >> > > > >
> > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > >> > > > > > > > >> > >
> > > > > >> > >> > > > > > > > >> >
> > > > > >> > >> > > > > > > > >> >
> > > > > >> > >> > > > > > > > >> > --
> > > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > > >> > >> > > > > > > > >> >
> > > > > >> > >> > > > > > > > >>
> > > > > >> > >> > > > > > > > >
> > > > > >> > >> > > > > > > >
> > > > > >> > >> > > > > > >
> > > > > >> > >> > > > > >
> > > > > >> > >> > > > >
> > > > > >> > >> > > >
> > > > > >> > >> > >
> > > > > >> > >> >
> > > > > >> > >>
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > > Ivan Pavlukhin
> > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <is...@apache.org>:
> 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 <pl...@gmail.com>
> 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, Павлухин Иван <vo...@gmail.com>:
> >
> > > 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 <pl...@gmail.com>:
> > > >
> > > > 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 <pl...@gmail.com>:
> > > >
> > > > > Vladimir,
> > > > >
> > > > > Ok, then I will rewrite IEP in the near future.
> > > > >
> > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <vozerov@gridgain.com
> >:
> > > > >
> > > > >> 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 <
> > > plehanov.alex@gmail.com>
> > > > >> 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 <
> > plehanov.alex@gmail.com
> > > >:
> > > > >> >
> > > > >> > > 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.kasnacheev@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 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 <
> > ptupitsyn@apache.org
> > > >:
> > > > >> > >>
> > > > >> > >> > 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 <
> > > > >> plehanov.alex@gmail.com
> > > > >> > >
> > > > >> > >> > 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 <
> > > dpavlov@apache.org
> > > > >> >:
> > > > >> > >> > >
> > > > >> > >> > > > 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 <
> > > > >> > plehanov.alex@gmail.com
> > > > >> > >> >:
> > > > >> > >> > > >
> > > > >> > >> > > > > 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 <
> > > > >> > >> vozerov@gridgain.com>:
> > > > >> > >> > > > >
> > > > >> > >> > > > > > 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.alex@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 <
> > > > >> > >> > vozerov@gridgain.com
> > > > >> > >> > > >:
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > > 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
> > <
> > > > >> > >> > > > > vozerov@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.alex@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 <
> > > > >> > >> > > > skozlov@gridgain.com
> > > > >> > >> > > > > >:
> > > > >> > >> > > > > > > > >>
> > > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > > >> > >> > > > > > nizhikov@apache.org
> > > > >> > >> > > > > > > >:
> > > > >> > >> > > > > > > > >> > >
> > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > > operations.
> > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey
> > Kozlov
> > > <
> > > > >> > >> > > > > > skozlov@gridgain.com
> > > > >> > >> > > > > > > >:
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > > >> > >> > > > > > > > >> > > > > > 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 <
> > > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > > >> > >> > > > > > > > >> > >:
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > 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
> > > > >> > >> <
> > > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > > >> > >> > > > > > > > >> > > > > 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
> > > > >> > >> > > > <
> > > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > >
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > > --
> > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > >
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > --
> > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >>
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > >
> > > > >> > >> > > >
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Igor Sapego <is...@apache.org>.
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 <pl...@gmail.com>
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, Павлухин Иван <vo...@gmail.com>:
>
> > 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 <pl...@gmail.com>:
> > >
> > > 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 <pl...@gmail.com>:
> > >
> > > > Vladimir,
> > > >
> > > > Ok, then I will rewrite IEP in the near future.
> > > >
> > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <vo...@gridgain.com>:
> > > >
> > > >> 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 <
> > plehanov.alex@gmail.com>
> > > >> 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 <
> plehanov.alex@gmail.com
> > >:
> > > >> >
> > > >> > > 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.kasnacheev@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 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 <
> ptupitsyn@apache.org
> > >:
> > > >> > >>
> > > >> > >> > 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 <
> > > >> plehanov.alex@gmail.com
> > > >> > >
> > > >> > >> > 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 <
> > dpavlov@apache.org
> > > >> >:
> > > >> > >> > >
> > > >> > >> > > > 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 <
> > > >> > plehanov.alex@gmail.com
> > > >> > >> >:
> > > >> > >> > > >
> > > >> > >> > > > > 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 <
> > > >> > >> vozerov@gridgain.com>:
> > > >> > >> > > > >
> > > >> > >> > > > > > 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.alex@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 <
> > > >> > >> > vozerov@gridgain.com
> > > >> > >> > > >:
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > > 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
> <
> > > >> > >> > > > > vozerov@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.alex@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 <
> > > >> > >> > > > skozlov@gridgain.com
> > > >> > >> > > > > >:
> > > >> > >> > > > > > > > >>
> > > >> > >> > > > > > > > >> > 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.alex@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 <
> > > >> > >> > > > > > nizhikov@apache.org
> > > >> > >> > > > > > > >:
> > > >> > >> > > > > > > > >> > >
> > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > operations.
> > > >> > >> > > > > > > > >> > > > I think we should support them
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey
> Kozlov
> > <
> > > >> > >> > > > > > skozlov@gridgain.com
> > > >> > >> > > > > > > >:
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > > 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.alex@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
> > > >> > >> > > > > > > > >> > > > > > 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 <
> > > >> > >> > > > > > > > >> vozerov@gridgain.com
> > > >> > >> > > > > > > > >> > >:
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > > 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
> > > >> > >> <
> > > >> > >> > > > > > > > >> dmagda@apache.org>
> > > >> > >> > > > > > > > >> > > > > 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
> > > >> > >> > > > <
> > > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > >> > >> > > > > > > > >> > > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > >
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > > --
> > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > >
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > --
> > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > >> > >> > > > > > > > >> > GridGain Systems
> > > >> > >> > > > > > > > >> > www.gridgain.com
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >>
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > >
> > > >> > >> > > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> > >
> > > >> >
> > > >>
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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, Павлухин Иван <vo...@gmail.com>:
> 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 <pl...@gmail.com>:
> >
> > 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 <pl...@gmail.com>:
> >
> > > Vladimir,
> > >
> > > Ok, then I will rewrite IEP in the near future.
> > >
> > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <vo...@gridgain.com>:
> > >
> > >> 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 <
> plehanov.alex@gmail.com>
> > >> 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 <plehanov.alex@gmail.com
> >:
> > >> >
> > >> > > 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.kasnacheev@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 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 <ptupitsyn@apache.org
> >:
> > >> > >>
> > >> > >> > 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 <
> > >> plehanov.alex@gmail.com
> > >> > >
> > >> > >> > 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 <
> dpavlov@apache.org
> > >> >:
> > >> > >> > >
> > >> > >> > > > 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 <
> > >> > plehanov.alex@gmail.com
> > >> > >> >:
> > >> > >> > > >
> > >> > >> > > > > 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 <
> > >> > >> vozerov@gridgain.com>:
> > >> > >> > > > >
> > >> > >> > > > > > 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.alex@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 <
> > >> > >> > vozerov@gridgain.com
> > >> > >> > > >:
> > >> > >> > > > > > >
> > >> > >> > > > > > > > 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 <
> > >> > >> > > > > vozerov@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.alex@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 <
> > >> > >> > > > skozlov@gridgain.com
> > >> > >> > > > > >:
> > >> > >> > > > > > > > >>
> > >> > >> > > > > > > > >> > 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.alex@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 <
> > >> > >> > > > > > nizhikov@apache.org
> > >> > >> > > > > > > >:
> > >> > >> > > > > > > > >> > >
> > >> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > We also have suspend and resume
> operations.
> > >> > >> > > > > > > > >> > > > I think we should support them
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov
> <
> > >> > >> > > > > > skozlov@gridgain.com
> > >> > >> > > > > > > >:
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > > 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.alex@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
> > >> > >> > > > > > > > >> > > > > > 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 <
> > >> > >> > > > > > > > >> vozerov@gridgain.com
> > >> > >> > > > > > > > >> > >:
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > > 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
> > >> > >> <
> > >> > >> > > > > > > > >> dmagda@apache.org>
> > >> > >> > > > > > > > >> > > > > 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
> > >> > >> > > > <
> > >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > >> > >> > > > > > > > >> > > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > > >> > > > > > >
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > > --
> > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > >> > >> > > > > > > > >> > > > > GridGain Systems
> > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > >
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > --
> > >> > >> > > > > > > > >> > Sergey Kozlov
> > >> > >> > > > > > > > >> > GridGain Systems
> > >> > >> > > > > > > > >> > www.gridgain.com
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >>
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > > >
> > >> > >> > > > >
> > >> > >> > > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> >
> > >>
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
>
Re: Thin client: transactions support
Posted by Павлухин Иван <vo...@gmail.com>.
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 <pl...@gmail.com>:
>
> 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 <pl...@gmail.com>:
>
> > Vladimir,
> >
> > Ok, then I will rewrite IEP in the near future.
> >
> > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <vo...@gridgain.com>:
> >
> >> 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 <pl...@gmail.com>
> >> 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 <pl...@gmail.com>:
> >> >
> >> > > 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.kasnacheev@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 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 <pt...@apache.org>:
> >> > >>
> >> > >> > 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 <
> >> plehanov.alex@gmail.com
> >> > >
> >> > >> > 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 <dpavlov@apache.org
> >> >:
> >> > >> > >
> >> > >> > > > 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 <
> >> > plehanov.alex@gmail.com
> >> > >> >:
> >> > >> > > >
> >> > >> > > > > 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 <
> >> > >> vozerov@gridgain.com>:
> >> > >> > > > >
> >> > >> > > > > > 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.alex@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 <
> >> > >> > vozerov@gridgain.com
> >> > >> > > >:
> >> > >> > > > > > >
> >> > >> > > > > > > > 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 <
> >> > >> > > > > vozerov@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.alex@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 <
> >> > >> > > > skozlov@gridgain.com
> >> > >> > > > > >:
> >> > >> > > > > > > > >>
> >> > >> > > > > > > > >> > 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.alex@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 <
> >> > >> > > > > > nizhikov@apache.org
> >> > >> > > > > > > >:
> >> > >> > > > > > > > >> > >
> >> > >> > > > > > > > >> > > > Hello, Alex.
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > We also have suspend and resume operations.
> >> > >> > > > > > > > >> > > > I think we should support them
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> >> > >> > > > > > skozlov@gridgain.com
> >> > >> > > > > > > >:
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > > 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.alex@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
> >> > >> > > > > > > > >> > > > > > 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 <
> >> > >> > > > > > > > >> vozerov@gridgain.com
> >> > >> > > > > > > > >> > >:
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > > 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
> >> > >> <
> >> > >> > > > > > > > >> dmagda@apache.org>
> >> > >> > > > > > > > >> > > > > 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
> >> > >> > > > <
> >> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> >> > >> > > > > > > > >> > > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > > >> > > > > > >
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > > --
> >> > >> > > > > > > > >> > > > > Sergey Kozlov
> >> > >> > > > > > > > >> > > > > GridGain Systems
> >> > >> > > > > > > > >> > > > > www.gridgain.com
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > >
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > --
> >> > >> > > > > > > > >> > Sergey Kozlov
> >> > >> > > > > > > > >> > GridGain Systems
> >> > >> > > > > > > > >> > www.gridgain.com
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >>
> >> > >> > > > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > >
> >> > >> > > > >
> >> > >> > > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
> >
--
Best regards,
Ivan Pavlukhin
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pl...@gmail.com>:
> Vladimir,
>
> Ok, then I will rewrite IEP in the near future.
>
> чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <vo...@gridgain.com>:
>
>> 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 <pl...@gmail.com>
>> 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 <pl...@gmail.com>:
>> >
>> > > 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.kasnacheev@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 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 <pt...@apache.org>:
>> > >>
>> > >> > 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 <
>> plehanov.alex@gmail.com
>> > >
>> > >> > 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 <dpavlov@apache.org
>> >:
>> > >> > >
>> > >> > > > 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 <
>> > plehanov.alex@gmail.com
>> > >> >:
>> > >> > > >
>> > >> > > > > 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 <
>> > >> vozerov@gridgain.com>:
>> > >> > > > >
>> > >> > > > > > 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.alex@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 <
>> > >> > vozerov@gridgain.com
>> > >> > > >:
>> > >> > > > > > >
>> > >> > > > > > > > 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 <
>> > >> > > > > vozerov@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.alex@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 <
>> > >> > > > skozlov@gridgain.com
>> > >> > > > > >:
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> > 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.alex@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 <
>> > >> > > > > > nizhikov@apache.org
>> > >> > > > > > > >:
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > > Hello, Alex.
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > We also have suspend and resume operations.
>> > >> > > > > > > > >> > > > I think we should support them
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
>> > >> > > > > > skozlov@gridgain.com
>> > >> > > > > > > >:
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > > 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.alex@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
>> > >> > > > > > > > >> > > > > > 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 <
>> > >> > > > > > > > >> vozerov@gridgain.com
>> > >> > > > > > > > >> > >:
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > > 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
>> > >> <
>> > >> > > > > > > > >> dmagda@apache.org>
>> > >> > > > > > > > >> > > > > 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
>> > >> > > > <
>> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
>> > >> > > > > > > > >> > > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > >
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > > >> > > > > > >
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > > --
>> > >> > > > > > > > >> > > > > Sergey Kozlov
>> > >> > > > > > > > >> > > > > GridGain Systems
>> > >> > > > > > > > >> > > > > www.gridgain.com
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > --
>> > >> > > > > > > > >> > Sergey Kozlov
>> > >> > > > > > > > >> > GridGain Systems
>> > >> > > > > > > > >> > www.gridgain.com
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >>
>> > >> > > > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > >
>> > >> > > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
Vladimir,
Ok, then I will rewrite IEP in the near future.
чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <vo...@gridgain.com>:
> 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 <pl...@gmail.com>
> 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 <pl...@gmail.com>:
> >
> > > 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.kasnacheev@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 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 <pt...@apache.org>:
> > >>
> > >> > 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 <
> plehanov.alex@gmail.com
> > >
> > >> > 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 <dp...@apache.org>:
> > >> > >
> > >> > > > 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 <
> > plehanov.alex@gmail.com
> > >> >:
> > >> > > >
> > >> > > > > 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 <
> > >> vozerov@gridgain.com>:
> > >> > > > >
> > >> > > > > > 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.alex@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 <
> > >> > vozerov@gridgain.com
> > >> > > >:
> > >> > > > > > >
> > >> > > > > > > > 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 <
> > >> > > > > vozerov@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.alex@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 <
> > >> > > > skozlov@gridgain.com
> > >> > > > > >:
> > >> > > > > > > > >>
> > >> > > > > > > > >> > 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.alex@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 <
> > >> > > > > > nizhikov@apache.org
> > >> > > > > > > >:
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > We also have suspend and resume operations.
> > >> > > > > > > > >> > > > I think we should support them
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > >> > > > > > skozlov@gridgain.com
> > >> > > > > > > >:
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > > 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.alex@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
> > >> > > > > > > > >> > > > > > 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 <
> > >> > > > > > > > >> vozerov@gridgain.com
> > >> > > > > > > > >> > >:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > > 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
> > >> <
> > >> > > > > > > > >> dmagda@apache.org>
> > >> > > > > > > > >> > > > > 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
> > >> > > > <
> > >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > >> > > > > > > > >> > > > > > > > > >
> > >> > > > > > > > >> > > > > > > > >
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > --
> > >> > > > > > > > >> > > > > Sergey Kozlov
> > >> > > > > > > > >> > > > > GridGain Systems
> > >> > > > > > > > >> > > > > www.gridgain.com
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > --
> > >> > > > > > > > >> > Sergey Kozlov
> > >> > > > > > > > >> > GridGain Systems
> > >> > > > > > > > >> > www.gridgain.com
> > >> > > > > > > > >> >
> > >> > > > > > > > >>
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: Thin client: transactions support
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <pl...@gmail.com>
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 <pl...@gmail.com>:
>
> > 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 <il...@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 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 <pt...@apache.org>:
> >>
> >> > 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 <plehanov.alex@gmail.com
> >
> >> > 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 <dp...@apache.org>:
> >> > >
> >> > > > 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 <
> plehanov.alex@gmail.com
> >> >:
> >> > > >
> >> > > > > 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 <
> >> vozerov@gridgain.com>:
> >> > > > >
> >> > > > > > 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.alex@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 <
> >> > vozerov@gridgain.com
> >> > > >:
> >> > > > > > >
> >> > > > > > > > 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 <
> >> > > > > vozerov@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.alex@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 <
> >> > > > skozlov@gridgain.com
> >> > > > > >:
> >> > > > > > > > >>
> >> > > > > > > > >> > 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.alex@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 <
> >> > > > > > nizhikov@apache.org
> >> > > > > > > >:
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > > Hello, Alex.
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > We also have suspend and resume operations.
> >> > > > > > > > >> > > > I think we should support them
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> >> > > > > > skozlov@gridgain.com
> >> > > > > > > >:
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > > 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.alex@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
> >> > > > > > > > >> > > > > > 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 <
> >> > > > > > > > >> vozerov@gridgain.com
> >> > > > > > > > >> > >:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > > 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
> >> <
> >> > > > > > > > >> dmagda@apache.org>
> >> > > > > > > > >> > > > > 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
> >> > > > <
> >> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> >> > > > > > > > >> > > > > > > > > >
> >> > > > > > > > >> > > > > > > > >
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > --
> >> > > > > > > > >> > > > > Sergey Kozlov
> >> > > > > > > > >> > > > > GridGain Systems
> >> > > > > > > > >> > > > > www.gridgain.com
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > >
> >> > > > > > > > >> >
> >> > > > > > > > >> >
> >> > > > > > > > >> > --
> >> > > > > > > > >> > Sergey Kozlov
> >> > > > > > > > >> > GridGain Systems
> >> > > > > > > > >> > www.gridgain.com
> >> > > > > > > > >> >
> >> > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pl...@gmail.com>:
> 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 <il...@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 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 <pt...@apache.org>:
>>
>> > 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 <pl...@gmail.com>
>> > 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 <dp...@apache.org>:
>> > >
>> > > > 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 <plehanov.alex@gmail.com
>> >:
>> > > >
>> > > > > 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 <
>> vozerov@gridgain.com>:
>> > > > >
>> > > > > > 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.alex@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 <
>> > vozerov@gridgain.com
>> > > >:
>> > > > > > >
>> > > > > > > > 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 <
>> > > > > vozerov@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.alex@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 <
>> > > > skozlov@gridgain.com
>> > > > > >:
>> > > > > > > > >>
>> > > > > > > > >> > 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.alex@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 <
>> > > > > > nizhikov@apache.org
>> > > > > > > >:
>> > > > > > > > >> > >
>> > > > > > > > >> > > > Hello, Alex.
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > We also have suspend and resume operations.
>> > > > > > > > >> > > > I think we should support them
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
>> > > > > > skozlov@gridgain.com
>> > > > > > > >:
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > > 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.alex@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
>> > > > > > > > >> > > > > > 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 <
>> > > > > > > > >> vozerov@gridgain.com
>> > > > > > > > >> > >:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > > 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
>> <
>> > > > > > > > >> dmagda@apache.org>
>> > > > > > > > >> > > > > 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
>> > > > <
>> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
>> > > > > > > > >> > > > > > > > > >
>> > > > > > > > >> > > > > > > > >
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > --
>> > > > > > > > >> > > > > Sergey Kozlov
>> > > > > > > > >> > > > > GridGain Systems
>> > > > > > > > >> > > > > www.gridgain.com
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > >
>> > > > > > > > >> > >
>> > > > > > > > >> >
>> > > > > > > > >> >
>> > > > > > > > >> > --
>> > > > > > > > >> > Sergey Kozlov
>> > > > > > > > >> > GridGain Systems
>> > > > > > > > >> > www.gridgain.com
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <il...@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 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 <pt...@apache.org>:
>
> > 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 <pl...@gmail.com>
> > 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 <dp...@apache.org>:
> > >
> > > > 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 <plehanov.alex@gmail.com
> >:
> > > >
> > > > > 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 <vozerov@gridgain.com
> >:
> > > > >
> > > > > > 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.alex@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 <
> > vozerov@gridgain.com
> > > >:
> > > > > > >
> > > > > > > > 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 <
> > > > > vozerov@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.alex@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 <
> > > > skozlov@gridgain.com
> > > > > >:
> > > > > > > > >>
> > > > > > > > >> > 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.alex@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 <
> > > > > > nizhikov@apache.org
> > > > > > > >:
> > > > > > > > >> > >
> > > > > > > > >> > > > Hello, Alex.
> > > > > > > > >> > > >
> > > > > > > > >> > > > We also have suspend and resume operations.
> > > > > > > > >> > > > I think we should support them
> > > > > > > > >> > > >
> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > > > > > skozlov@gridgain.com
> > > > > > > >:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > 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.alex@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
> > > > > > > > >> > > > > > 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 <
> > > > > > > > >> vozerov@gridgain.com
> > > > > > > > >> > >:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > 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 <
> > > > > > > > >> dmagda@apache.org>
> > > > > > > > >> > > > > 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
> > > > <
> > > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > --
> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > > > >> > > > > GridGain Systems
> > > > > > > > >> > > > > www.gridgain.com
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > --
> > > > > > > > >> > Sergey Kozlov
> > > > > > > > >> > GridGain Systems
> > > > > > > > >> > www.gridgain.com
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Ilya Kasnacheev <il...@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 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 <pt...@apache.org>:
> 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 <pl...@gmail.com>
> 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 <dp...@apache.org>:
> >
> > > 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 <pl...@gmail.com>:
> > >
> > > > 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 <vo...@gridgain.com>:
> > > >
> > > > > 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.alex@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 <
> vozerov@gridgain.com
> > >:
> > > > > >
> > > > > > > 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 <
> > > > vozerov@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.alex@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 <
> > > skozlov@gridgain.com
> > > > >:
> > > > > > > >>
> > > > > > > >> > 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.alex@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 <
> > > > > nizhikov@apache.org
> > > > > > >:
> > > > > > > >> > >
> > > > > > > >> > > > Hello, Alex.
> > > > > > > >> > > >
> > > > > > > >> > > > We also have suspend and resume operations.
> > > > > > > >> > > > I think we should support them
> > > > > > > >> > > >
> > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > > > > skozlov@gridgain.com
> > > > > > >:
> > > > > > > >> > > >
> > > > > > > >> > > > > 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.alex@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
> > > > > > > >> > > > > > 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 <
> > > > > > > >> vozerov@gridgain.com
> > > > > > > >> > >:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > 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 <
> > > > > > > >> dmagda@apache.org>
> > > > > > > >> > > > > 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
> > > <
> > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > > --
> > > > > > > >> > > > > Sergey Kozlov
> > > > > > > >> > > > > GridGain Systems
> > > > > > > >> > > > > www.gridgain.com
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > --
> > > > > > > >> > Sergey Kozlov
> > > > > > > >> > GridGain Systems
> > > > > > > >> > www.gridgain.com
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <pt...@apache.org>:
> 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 <pl...@gmail.com>
> 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 <dp...@apache.org>:
> >
> > > 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 <pl...@gmail.com>:
> > >
> > > > 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 <vo...@gridgain.com>:
> > > >
> > > > > 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.alex@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 <
> vozerov@gridgain.com
> > >:
> > > > > >
> > > > > > > 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 <
> > > > vozerov@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.alex@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 <
> > > skozlov@gridgain.com
> > > > >:
> > > > > > > >>
> > > > > > > >> > 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.alex@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 <
> > > > > nizhikov@apache.org
> > > > > > >:
> > > > > > > >> > >
> > > > > > > >> > > > Hello, Alex.
> > > > > > > >> > > >
> > > > > > > >> > > > We also have suspend and resume operations.
> > > > > > > >> > > > I think we should support them
> > > > > > > >> > > >
> > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > > > > skozlov@gridgain.com
> > > > > > >:
> > > > > > > >> > > >
> > > > > > > >> > > > > 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.alex@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
> > > > > > > >> > > > > > 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 <
> > > > > > > >> vozerov@gridgain.com
> > > > > > > >> > >:
> > > > > > > >> > > > > >
> > > > > > > >> > > > > > > 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 <
> > > > > > > >> dmagda@apache.org>
> > > > > > > >> > > > > 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
> > > <
> > > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > >> > > > > > > > > >
> > > > > > > >> > > > > > > > >
> > > > > > > >> > > > > > > >
> > > > > > > >> > > > > > >
> > > > > > > >> > > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > >
> > > > > > > >> > > > > --
> > > > > > > >> > > > > Sergey Kozlov
> > > > > > > >> > > > > GridGain Systems
> > > > > > > >> > > > > www.gridgain.com
> > > > > > > >> > > > >
> > > > > > > >> > > >
> > > > > > > >> > >
> > > > > > > >> >
> > > > > > > >> >
> > > > > > > >> > --
> > > > > > > >> > Sergey Kozlov
> > > > > > > >> > GridGain Systems
> > > > > > > >> > www.gridgain.com
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Pavel Tupitsyn <pt...@apache.org>.
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 <pl...@gmail.com>
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 <dp...@apache.org>:
>
> > 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 <pl...@gmail.com>:
> >
> > > 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 <vo...@gridgain.com>:
> > >
> > > > 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.alex@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 <vozerov@gridgain.com
> >:
> > > > >
> > > > > > 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 <
> > > vozerov@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.alex@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 <
> > skozlov@gridgain.com
> > > >:
> > > > > > >>
> > > > > > >> > 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.alex@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 <
> > > > nizhikov@apache.org
> > > > > >:
> > > > > > >> > >
> > > > > > >> > > > Hello, Alex.
> > > > > > >> > > >
> > > > > > >> > > > We also have suspend and resume operations.
> > > > > > >> > > > I think we should support them
> > > > > > >> > > >
> > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > > > skozlov@gridgain.com
> > > > > >:
> > > > > > >> > > >
> > > > > > >> > > > > 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.alex@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
> > > > > > >> > > > > > 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 <
> > > > > > >> vozerov@gridgain.com
> > > > > > >> > >:
> > > > > > >> > > > > >
> > > > > > >> > > > > > > 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 <
> > > > > > >> dmagda@apache.org>
> > > > > > >> > > > > 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
> > <
> > > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > >> > > > > > > > > >
> > > > > > >> > > > > > > > >
> > > > > > >> > > > > > > >
> > > > > > >> > > > > > >
> > > > > > >> > > > > >
> > > > > > >> > > > >
> > > > > > >> > > > >
> > > > > > >> > > > > --
> > > > > > >> > > > > Sergey Kozlov
> > > > > > >> > > > > GridGain Systems
> > > > > > >> > > > > www.gridgain.com
> > > > > > >> > > > >
> > > > > > >> > > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > --
> > > > > > >> > Sergey Kozlov
> > > > > > >> > GridGain Systems
> > > > > > >> > www.gridgain.com
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <dp...@apache.org>:
> 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 <pl...@gmail.com>:
>
> > 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 <vo...@gridgain.com>:
> >
> > > 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.alex@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 <vo...@gridgain.com>:
> > > >
> > > > > 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 <
> > vozerov@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.alex@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 <
> skozlov@gridgain.com
> > >:
> > > > > >>
> > > > > >> > 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.alex@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 <
> > > nizhikov@apache.org
> > > > >:
> > > > > >> > >
> > > > > >> > > > Hello, Alex.
> > > > > >> > > >
> > > > > >> > > > We also have suspend and resume operations.
> > > > > >> > > > I think we should support them
> > > > > >> > > >
> > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > > skozlov@gridgain.com
> > > > >:
> > > > > >> > > >
> > > > > >> > > > > 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.alex@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
> > > > > >> > > > > > 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 <
> > > > > >> vozerov@gridgain.com
> > > > > >> > >:
> > > > > >> > > > > >
> > > > > >> > > > > > > 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 <
> > > > > >> dmagda@apache.org>
> > > > > >> > > > > 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
> <
> > > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > >> > > > > > > > > >
> > > > > >> > > > > > > > >
> > > > > >> > > > > > > >
> > > > > >> > > > > > >
> > > > > >> > > > > >
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > > > > --
> > > > > >> > > > > Sergey Kozlov
> > > > > >> > > > > GridGain Systems
> > > > > >> > > > > www.gridgain.com
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Sergey Kozlov
> > > > > >> > GridGain Systems
> > > > > >> > www.gridgain.com
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Dmitriy Pavlov <dp...@apache.org>.
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 <pl...@gmail.com>:
> 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 <vo...@gridgain.com>:
>
> > 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 <pl...@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 <vo...@gridgain.com>:
> > >
> > > > 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 <
> vozerov@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.alex@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 <skozlov@gridgain.com
> >:
> > > > >>
> > > > >> > 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.alex@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 <
> > nizhikov@apache.org
> > > >:
> > > > >> > >
> > > > >> > > > Hello, Alex.
> > > > >> > > >
> > > > >> > > > We also have suspend and resume operations.
> > > > >> > > > I think we should support them
> > > > >> > > >
> > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > skozlov@gridgain.com
> > > >:
> > > > >> > > >
> > > > >> > > > > 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.alex@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
> > > > >> > > > > > 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 <
> > > > >> vozerov@gridgain.com
> > > > >> > >:
> > > > >> > > > > >
> > > > >> > > > > > > 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 <
> > > > >> dmagda@apache.org>
> > > > >> > > > > 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 <
> > > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > > >> > > > > > > > > >
> > > > >> > > > > > > > >
> > > > >> > > > > > > >
> > > > >> > > > > > >
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > --
> > > > >> > > > > Sergey Kozlov
> > > > >> > > > > GridGain Systems
> > > > >> > > > > www.gridgain.com
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Sergey Kozlov
> > > > >> > GridGain Systems
> > > > >> > www.gridgain.com
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <vo...@gridgain.com>:
> 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 <pl...@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 <vo...@gridgain.com>:
> >
> > > 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 <vozerov@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.alex@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 <sk...@gridgain.com>:
> > > >>
> > > >> > 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.alex@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 <
> nizhikov@apache.org
> > >:
> > > >> > >
> > > >> > > > Hello, Alex.
> > > >> > > >
> > > >> > > > We also have suspend and resume operations.
> > > >> > > > I think we should support them
> > > >> > > >
> > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> skozlov@gridgain.com
> > >:
> > > >> > > >
> > > >> > > > > 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.alex@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
> > > >> > > > > > 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 <
> > > >> vozerov@gridgain.com
> > > >> > >:
> > > >> > > > > >
> > > >> > > > > > > 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 <
> > > >> dmagda@apache.org>
> > > >> > > > > 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 <
> > > >> > > > > > dsetrakyan@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.govorukhin@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.
> > > >> > > > > > > > > >
> > > >> > > > > > > > >
> > > >> > > > > > > >
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > --
> > > >> > > > > Sergey Kozlov
> > > >> > > > > GridGain Systems
> > > >> > > > > www.gridgain.com
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sergey Kozlov
> > > >> > GridGain Systems
> > > >> > www.gridgain.com
> > > >> >
> > > >>
> > > >
> > >
> >
>
Re: Thin client: transactions support
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <pl...@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 <vo...@gridgain.com>:
>
> > 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 <vo...@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.alex@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 <sk...@gridgain.com>:
> > >>
> > >> > 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.alex@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 <nizhikov@apache.org
> >:
> > >> > >
> > >> > > > Hello, Alex.
> > >> > > >
> > >> > > > We also have suspend and resume operations.
> > >> > > > I think we should support them
> > >> > > >
> > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <skozlov@gridgain.com
> >:
> > >> > > >
> > >> > > > > 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.alex@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
> > >> > > > > > 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 <
> > >> vozerov@gridgain.com
> > >> > >:
> > >> > > > > >
> > >> > > > > > > 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 <
> > >> dmagda@apache.org>
> > >> > > > > 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 <
> > >> > > > > > dsetrakyan@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.govorukhin@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.
> > >> > > > > > > > > >
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > > --
> > >> > > > > Sergey Kozlov
> > >> > > > > GridGain Systems
> > >> > > > > www.gridgain.com
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > Sergey Kozlov
> > >> > GridGain Systems
> > >> > www.gridgain.com
> > >> >
> > >>
> > >
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <vo...@gridgain.com>:
> 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 <vo...@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 <pl...@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 <sk...@gridgain.com>:
> >>
> >> > 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.alex@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 <ni...@apache.org>:
> >> > >
> >> > > > Hello, Alex.
> >> > > >
> >> > > > We also have suspend and resume operations.
> >> > > > I think we should support them
> >> > > >
> >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
> >> > > >
> >> > > > > 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.alex@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
> >> > > > > > 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 <
> >> vozerov@gridgain.com
> >> > >:
> >> > > > > >
> >> > > > > > > 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 <
> >> dmagda@apache.org>
> >> > > > > 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 <
> >> > > > > > dsetrakyan@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.govorukhin@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.
> >> > > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Sergey Kozlov
> >> > > > > GridGain Systems
> >> > > > > www.gridgain.com
> >> > > > >
> >> > > >
> >> > >
> >> >
> >> >
> >> > --
> >> > Sergey Kozlov
> >> > GridGain Systems
> >> > www.gridgain.com
> >> >
> >>
> >
>
Re: Thin client: transactions support
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <vo...@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 <pl...@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 <sk...@gridgain.com>:
>>
>> > 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.alex@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 <ni...@apache.org>:
>> > >
>> > > > Hello, Alex.
>> > > >
>> > > > We also have suspend and resume operations.
>> > > > I think we should support them
>> > > >
>> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
>> > > >
>> > > > > 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.alex@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
>> > > > > > 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 <
>> vozerov@gridgain.com
>> > >:
>> > > > > >
>> > > > > > > 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 <
>> dmagda@apache.org>
>> > > > > 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 <
>> > > > > > dsetrakyan@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.govorukhin@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.
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Sergey Kozlov
>> > > > > GridGain Systems
>> > > > > www.gridgain.com
>> > > > >
>> > > >
>> > >
>> >
>> >
>> > --
>> > Sergey Kozlov
>> > GridGain Systems
>> > www.gridgain.com
>> >
>>
>
Re: Thin client: transactions support
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <pl...@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 <sk...@gridgain.com>:
>
> > 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 <pl...@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 <ni...@apache.org>:
> > >
> > > > Hello, Alex.
> > > >
> > > > We also have suspend and resume operations.
> > > > I think we should support them
> > > >
> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
> > > >
> > > > > 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.alex@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
> > > > > > 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 <
> vozerov@gridgain.com
> > >:
> > > > > >
> > > > > > > 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 <
> dmagda@apache.org>
> > > > > 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 <
> > > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sergey Kozlov
> > > > > GridGain Systems
> > > > > www.gridgain.com
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <sk...@gridgain.com>:
> 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 <pl...@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 <ni...@apache.org>:
> >
> > > Hello, Alex.
> > >
> > > We also have suspend and resume operations.
> > > I think we should support them
> > >
> > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
> > >
> > > > 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.alex@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
> > > > > 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 <vozerov@gridgain.com
> >:
> > > > >
> > > > > > 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 <dm...@apache.org>
> > > > 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 <
> > > > > dsetrakyan@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.govorukhin@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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Sergey Kozlov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>
Re: Thin client: transactions support
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <pl...@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 <ni...@apache.org>:
>
> > Hello, Alex.
> >
> > We also have suspend and resume operations.
> > I think we should support them
> >
> > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
> >
> > > 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.alex@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
> > > > 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 <vo...@gridgain.com>:
> > > >
> > > > > 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 <dm...@apache.org>
> > > 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 <
> > > > dsetrakyan@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.govorukhin@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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Sergey Kozlov
> > > GridGain Systems
> > > www.gridgain.com
> > >
> >
>
--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <ni...@apache.org>:
> Hello, Alex.
>
> We also have suspend and resume operations.
> I think we should support them
>
> вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
>
> > 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 <pl...@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
> > > 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 <vo...@gridgain.com>:
> > >
> > > > 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 <dm...@apache.org>
> > 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 <
> > > dsetrakyan@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.govorukhin@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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>
Re: Thin client: transactions support
Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Alex.
We also have suspend and resume operations.
I think we should support them
вт, 26 марта 2019 г., 22:07 Sergey Kozlov <sk...@gridgain.com>:
> 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 <pl...@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
> > 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 <vo...@gridgain.com>:
> >
> > > 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 <dm...@apache.org>
> 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 <
> > dsetrakyan@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.govorukhin@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.
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
> --
> Sergey Kozlov
> GridGain Systems
> www.gridgain.com
>
Re: Thin client: transactions support
Posted by Sergey Kozlov <sk...@gridgain.com>.
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 <pl...@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
> 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 <vo...@gridgain.com>:
>
> > 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 <dm...@apache.org> 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 <
> dsetrakyan@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.govorukhin@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.
> > > > >
> > > >
> > >
> >
>
--
Sergey Kozlov
GridGain Systems
www.gridgain.com
Re: Thin client: transactions support
Posted by Alex Plehanov <pl...@gmail.com>.
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 <vo...@gridgain.com>:
> 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 <dm...@apache.org> 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 <dsetrakyan@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.govorukhin@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
Posted by Vladimir Ozerov <vo...@gridgain.com>.
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 <dm...@apache.org> 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 <ds...@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.govorukhin@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
Posted by Denis Magda <dm...@apache.org>.
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 <ds...@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.govorukhin@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
Posted by Dmitriy Setrakyan <ds...@apache.org>.
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.govorukhin@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.
>