ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Thin client: transactions support
Date Thu, 15 Aug 2019 08:46:16 GMT
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, Павлухин Иван <vololo100@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
> >
> >
>

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