Thin client: transactions support

[Alexey Plekhanov]

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

> 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, Павлухин Иван <[hidden email]>:
>
>> 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 <[hidden email]>:
>> >
>> > 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, Павлухин Иван <[hidden email]>:
>> >
>> > > 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 <[hidden email]>:
>> > > >
>> > > > 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 <[hidden email]>:
>> > > >
>> > > > > 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, Павлухин Иван <[hidden email]>:
>> > > > >
>> > > > >> Alex,
>> > > > >>
>> > > > >> Are you going to introduce settings specifying default values
>> for tx
>> > > > >> concurrency and isolation in client configuration?
>> > > > >>
>> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
>> [hidden email]>:
>> > > > >> >
>> > > > >> > 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 <[hidden email]>:
>> > > > >> >
>> > > > >> > > 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 Павлухин Иван <
>> > > [hidden email]>
>> > > > >> 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 <
>> [hidden email]>:
>> > > > >> > > > >
>> > > > >> > > > > 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 <
>> > > > >> > > [hidden email]>
>> > > > >> > > > > 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 <
>> [hidden email]
>> > > >:
>> > > > >> > > > > >
>> > > > >> > > > > > > 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 <
>> > > > >> > > > [hidden email]>
>> > > > >> > > > > > > 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, Павлухин Иван <
>> > > > >> [hidden email]>:
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > > 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 <
>> > > > >> > > > [hidden email]
>> > > > >> > > > > > >:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > 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 <
>> > > > >> > > > [hidden email]
>> > > > >> > > > > > >:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > > Vladimir,
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
>> future.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
>> > > > >> > > > > > [hidden email]
>> > > > >> > > > > > > >:
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > >> 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 <
>> > > > >> > > > > > > > > [hidden email]>
>> > > > >> > > > > > > > > > >> 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
>> <
>> > > > >> > > > > > > > [hidden email]
>> > > > >> > > > > > > > > >:
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > > 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 <
>> > > > >> > > > > > > > > > >> [hidden email]>:
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> 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 <
>> > > > >> > > > > > > > [hidden email]
>> > > > >> > > > > > > > > >:
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> > 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 <
>> > > > >> > > > > > > > > > >> [hidden email]
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > 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
>> > > > >> <
>> > > > >> > > > > > > > > [hidden email]
>> > > > >> > > > > > > > > > >> >:
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > 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 <
>> > > > >> > > > > > > > > > >> > [hidden email]
>> > > > >> > > > > > > > > > >> > >> >:
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > 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
>> > > > >> > > <
>> > > > >> > > > > > > > > > >> > >> [hidden email]>:
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
>> > > > >> > > > > > > > > > >> > >> > > > [hidden email]>
>> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
>> > > > >> > > > > > > > > > >> > >> > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
>> > > > >> > > > > > > > <
>> > > > >> > > > > > > > > > >> > >> > > > > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
>> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
>> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
>> > > > >> > > > > > > > > > >> > >> > > > > > > > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
>> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
>> suspend
>> > > and
>> > > > >> > > resume
>> > > > >> > > > > > > > > operations.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
>> should
>> > > > >> support them
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
>> 2019 г.,
>> > > > >> 22:07
>> > > > >> > > > Sergey
>> > > > >> > > > > > > > Kozlov
>> > > > >> > > > > > > > > <
>> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> [hidden email]
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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
>>
>

[Ivan Pavlukhin]

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

>
> 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 <[hidden email]>:
>
> > 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, Павлухин Иван <[hidden email]>:
> >
> >> 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 <[hidden email]>:
> >> >
> >> > 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, Павлухин Иван <[hidden email]>:
> >> >
> >> > > 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 <[hidden email]>:
> >> > > >
> >> > > > 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 <[hidden email]>:
> >> > > >
> >> > > > > 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, Павлухин Иван <[hidden email]>:
> >> > > > >
> >> > > > >> Alex,
> >> > > > >>
> >> > > > >> Are you going to introduce settings specifying default values
> >> for tx
> >> > > > >> concurrency and isolation in client configuration?
> >> > > > >>
> >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> >> [hidden email]>:
> >> > > > >> >
> >> > > > >> > 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 <[hidden email]>:
> >> > > > >> >
> >> > > > >> > > 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 Павлухин Иван <
> >> > > [hidden email]>
> >> > > > >> 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 <
> >> [hidden email]>:
> >> > > > >> > > > >
> >> > > > >> > > > > 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 <
> >> > > > >> > > [hidden email]>
> >> > > > >> > > > > 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 <
> >> [hidden email]
> >> > > >:
> >> > > > >> > > > > >
> >> > > > >> > > > > > > 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 <
> >> > > > >> > > > [hidden email]>
> >> > > > >> > > > > > > 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, Павлухин Иван <
> >> > > > >> [hidden email]>:
> >> > > > >> > > > > > > >
> >> > > > >> > > > > > > > > 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 <
> >> > > > >> > > > [hidden email]
> >> > > > >> > > > > > >:
> >> > > > >> > > > > > > > > >
> >> > > > >> > > > > > > > > > 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 <
> >> > > > >> > > > [hidden email]
> >> > > > >> > > > > > >:
> >> > > > >> > > > > > > > > >
> >> > > > >> > > > > > > > > > > Vladimir,
> >> > > > >> > > > > > > > > > >
> >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> >> future.
> >> > > > >> > > > > > > > > > >
> >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
> >> > > > >> > > > > > [hidden email]
> >> > > > >> > > > > > > >:
> >> > > > >> > > > > > > > > > >
> >> > > > >> > > > > > > > > > >> 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 <
> >> > > > >> > > > > > > > > [hidden email]>
> >> > > > >> > > > > > > > > > >> 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
> >> <
> >> > > > >> > > > > > > > [hidden email]
> >> > > > >> > > > > > > > > >:
> >> > > > >> > > > > > > > > > >> >
> >> > > > >> > > > > > > > > > >> > > 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 <
> >> > > > >> > > > > > > > > > >> [hidden email]>:
> >> > > > >> > > > > > > > > > >> > >
> >> > > > >> > > > > > > > > > >> > >> 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 <
> >> > > > >> > > > > > > > [hidden email]
> >> > > > >> > > > > > > > > >:
> >> > > > >> > > > > > > > > > >> > >>
> >> > > > >> > > > > > > > > > >> > >> > 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 <
> >> > > > >> > > > > > > > > > >> [hidden email]
> >> > > > >> > > > > > > > > > >> > >
> >> > > > >> > > > > > > > > > >> > >> > 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
> >> > > > >> <
> >> > > > >> > > > > > > > > [hidden email]
> >> > > > >> > > > > > > > > > >> >:
> >> > > > >> > > > > > > > > > >> > >> > >
> >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> >> > > > >> > > > > > > > > > >> > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> >:
> >> > > > >> > > > > > > > > > >> > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > 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
> >> > > > >> > > <
> >> > > > >> > > > > > > > > > >> > >> [hidden email]>:
> >> > > > >> > > > > > > > > > >> > >> > > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]>
> >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> >> > > > >> > > > > > > > > > >> > >> > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> >> > > > >> > > > > > > > <
> >> > > > >> > > > > > > > > > >> > >> > > > > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
> >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
> >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
> >> suspend
> >> > > and
> >> > > > >> > > resume
> >> > > > >> > > > > > > > > operations.
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
> >> should
> >> > > > >> support them
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
> >> 2019 г.,
> >> > > > >> 22:07
> >> > > > >> > > > Sergey
> >> > > > >> > > > > > > > Kozlov
> >> > > > >> > > > > > > > > <
> >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> >> [hidden email]
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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

[Alexey Plekhanov]

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, Павлухин Иван <[hidden email]>:

> 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 <[hidden email]>:
> >
> > 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 <[hidden email]>:
> >
> > > 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, Павлухин Иван <[hidden email]>:
> > >
> > >> 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 <[hidden email]>:
> > >> >
> > >> > 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, Павлухин Иван <[hidden email]>:
> > >> >
> > >> > > 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 <
> [hidden email]>:
> > >> > > >
> > >> > > > 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 <
> [hidden email]>:
> > >> > > >
> > >> > > > > 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, Павлухин Иван <
> [hidden email]>:
> > >> > > > >
> > >> > > > >> Alex,
> > >> > > > >>
> > >> > > > >> Are you going to introduce settings specifying default values
> > >> for tx
> > >> > > > >> concurrency and isolation in client configuration?
> > >> > > > >>
> > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> > >> [hidden email]>:
> > >> > > > >> >
> > >> > > > >> > 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 <
> [hidden email]>:
> > >> > > > >> >
> > >> > > > >> > > 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 Павлухин Иван <
> > >> > > [hidden email]>
> > >> > > > >> 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 <
> > >> [hidden email]>:
> > >> > > > >> > > > >
> > >> > > > >> > > > > 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 <
> > >> > > > >> > > [hidden email]>
> > >> > > > >> > > > > 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 <
> > >> [hidden email]
> > >> > > >:
> > >> > > > >> > > > > >
> > >> > > > >> > > > > > > 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 <
> > >> > > > >> > > > [hidden email]>
> > >> > > > >> > > > > > > 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, Павлухин Иван <
> > >> > > > >> [hidden email]>:
> > >> > > > >> > > > > > > >
> > >> > > > >> > > > > > > > > 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 <
> > >> > > > >> > > > [hidden email]
> > >> > > > >> > > > > > >:
> > >> > > > >> > > > > > > > > >
> > >> > > > >> > > > > > > > > > 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 <
> > >> > > > >> > > > [hidden email]
> > >> > > > >> > > > > > >:
> > >> > > > >> > > > > > > > > >
> > >> > > > >> > > > > > > > > > > Vladimir,
> > >> > > > >> > > > > > > > > > >
> > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> > >> future.
> > >> > > > >> > > > > > > > > > >
> > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir
> Ozerov <
> > >> > > > >> > > > > > [hidden email]
> > >> > > > >> > > > > > > >:
> > >> > > > >> > > > > > > > > > >
> > >> > > > >> > > > > > > > > > >> 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 <
> > >> > > > >> > > > > > > > > [hidden email]>
> > >> > > > >> > > > > > > > > > >> 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
> > >> <
> > >> > > > >> > > > > > > > [hidden email]
> > >> > > > >> > > > > > > > > >:
> > >> > > > >> > > > > > > > > > >> >
> > >> > > > >> > > > > > > > > > >> > > 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 <
> > >> > > > >> > > > > > > > > > >> [hidden email]>:
> > >> > > > >> > > > > > > > > > >> > >
> > >> > > > >> > > > > > > > > > >> > >> 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 <
> > >> > > > >> > > > > > > > [hidden email]
> > >> > > > >> > > > > > > > > >:
> > >> > > > >> > > > > > > > > > >> > >>
> > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > >> > > > >> > > > > > > > > > >> [hidden email]
> > >> > > > >> > > > > > > > > > >> > >
> > >> > > > >> > > > > > > > > > >> > >> > 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
> > >> > > > >> <
> > >> > > > >> > > > > > > > > [hidden email]
> > >> > > > >> > > > > > > > > > >> >:
> > >> > > > >> > > > > > > > > > >> > >> > >
> > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > >> > > > >> > > > > > > > > > >> > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> >:
> > >> > > > >> > > > > > > > > > >> > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > >> > > > >> > > <
> > >> > > > >> > > > > > > > > > >> > >> [hidden email]>:
> > >> > > > >> > > > > > > > > > >> > >> > > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]>
> > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > >> > > > >> > > > > > > > <
> > >> > > > >> > > > > > > > > > >> > >> > > > > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
> > >> suspend
> > >> > > and
> > >> > > > >> > > resume
> > >> > > > >> > > > > > > > > operations.
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
> > >> should
> > >> > > > >> support them
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
> > >> 2019 г.,
> > >> > > > >> 22:07
> > >> > > > >> > > > Sergey
> > >> > > > >> > > > > > > > Kozlov
> > >> > > > >> > > > > > > > > <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > >> [hidden email]
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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
>
>

[Pavel Tupitsyn]

Hi Alex,

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

On Thu, Aug 15, 2019 at 10:36 AM Alex Plehanov <[hidden email]>
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, Павлухин Иван <[hidden email]>:
>
> > 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 <[hidden email]>:
> > >
> > > 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 <[hidden email]>:
> > >
> > > > 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, Павлухин Иван <[hidden email]>:
> > > >
> > > >> 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 <[hidden email]
> >:
> > > >> >
> > > >> > 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, Павлухин Иван <[hidden email]>:
> > > >> >
> > > >> > > 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 <
> > [hidden email]>:
> > > >> > > >
> > > >> > > > 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 <
> > [hidden email]>:
> > > >> > > >
> > > >> > > > > 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, Павлухин Иван <
> > [hidden email]>:
> > > >> > > > >
> > > >> > > > >> Alex,
> > > >> > > > >>
> > > >> > > > >> Are you going to introduce settings specifying default
> values
> > > >> for tx
> > > >> > > > >> concurrency and isolation in client configuration?
> > > >> > > > >>
> > > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> > > >> [hidden email]>:
> > > >> > > > >> >
> > > >> > > > >> > 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 <
> > [hidden email]>:
> > > >> > > > >> >
> > > >> > > > >> > > 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 Павлухин Иван <
> > > >> > > [hidden email]>
> > > >> > > > >> 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 <
> > > >> [hidden email]>:
> > > >> > > > >> > > > >
> > > >> > > > >> > > > > 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 <
> > > >> > > > >> > > [hidden email]>
> > > >> > > > >> > > > > 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 <
> > > >> [hidden email]
> > > >> > > >:
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > > 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 <
> > > >> > > > >> > > > [hidden email]>
> > > >> > > > >> > > > > > > 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, Павлухин Иван <
> > > >> > > > >> [hidden email]>:
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > > > 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
> <
> > > >> > > > >> > > > [hidden email]
> > > >> > > > >> > > > > > >:
> > > >> > > > >> > > > > > > > > >
> > > >> > > > >> > > > > > > > > > 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 <
> > > >> > > > >> > > > [hidden email]
> > > >> > > > >> > > > > > >:
> > > >> > > > >> > > > > > > > > >
> > > >> > > > >> > > > > > > > > > > Vladimir,
> > > >> > > > >> > > > > > > > > > >
> > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
> > > >> future.
> > > >> > > > >> > > > > > > > > > >
> > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir
> > Ozerov <
> > > >> > > > >> > > > > > [hidden email]
> > > >> > > > >> > > > > > > >:
> > > >> > > > >> > > > > > > > > > >
> > > >> > > > >> > > > > > > > > > >> 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 <
> > > >> > > > >> > > > > > > > > [hidden email]>
> > > >> > > > >> > > > > > > > > > >> 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
> > > >> <
> > > >> > > > >> > > > > > > > [hidden email]
> > > >> > > > >> > > > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> >
> > > >> > > > >> > > > > > > > > > >> > > 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 <
> > > >> > > > >> > > > > > > > > > >> [hidden email]>:
> > > >> > > > >> > > > > > > > > > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> 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 <
> > > >> > > > >> > > > > > > > [hidden email]
> > > >> > > > >> > > > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >>
> > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > >> > > > >> > > > > > > > > > >> [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > >> > > > >> <
> > > >> > > > >> > > > > > > > > [hidden email]
> > > >> > > > >> > > > > > > > > > >> >:
> > > >> > > > >> > > > > > > > > > >> > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> >:
> > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > >> > > > >> > > <
> > > >> > > > >> > > > > > > > > > >> > >> [hidden email]>:
> > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]>
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > >> > > > >> > > > > > > > <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello,
> Alex.
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also
> have
> > > >> suspend
> > > >> > > and
> > > >> > > > >> > > resume
> > > >> > > > >> > > > > > > > > operations.
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
> > > >> should
> > > >> > > > >> support them
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26
> марта
> > > >> 2019 г.,
> > > >> > > > >> 22:07
> > > >> > > > >> > > > Sergey
> > > >> > > > >> > > > > > > > Kozlov
> > > >> > > > >> > > > > > > > > <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > >> [hidden email]
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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
> >
> >
>

[Alexey Plekhanov]

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

> 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 <[hidden email]>
> 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, Павлухин Иван <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > > >
> > > > 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 <[hidden email]>:
> > > >
> > > > > 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, Павлухин Иван <[hidden email]>:
> > > > >
> > > > >> 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 <
> [hidden email]
> > >:
> > > > >> >
> > > > >> > 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, Павлухин Иван <[hidden email]
> >:
> > > > >> >
> > > > >> > > 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 <
> > > [hidden email]>:
> > > > >> > > >
> > > > >> > > > 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 <
> > > [hidden email]>:
> > > > >> > > >
> > > > >> > > > > 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, Павлухин Иван <
> > > [hidden email]>:
> > > > >> > > > >
> > > > >> > > > >> Alex,
> > > > >> > > > >>
> > > > >> > > > >> Are you going to introduce settings specifying default
> > values
> > > > >> for tx
> > > > >> > > > >> concurrency and isolation in client configuration?
> > > > >> > > > >>
> > > > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> > > > >> [hidden email]>:
> > > > >> > > > >> >
> > > > >> > > > >> > 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 <
> > > [hidden email]>:
> > > > >> > > > >> >
> > > > >> > > > >> > > 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 Павлухин Иван <
> > > > >> > > [hidden email]>
> > > > >> > > > >> 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 <
> > > > >> [hidden email]>:
> > > > >> > > > >> > > > >
> > > > >> > > > >> > > > > 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 <
> > > > >> > > > >> > > [hidden email]>
> > > > >> > > > >> > > > > 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 <
> > > > >> [hidden email]
> > > > >> > > >:
> > > > >> > > > >> > > > > >
> > > > >> > > > >> > > > > > > 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 <
> > > > >> > > > >> > > > [hidden email]>
> > > > >> > > > >> > > > > > > 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, Павлухин Иван <
> > > > >> > > > >> [hidden email]>:
> > > > >> > > > >> > > > > > > >
> > > > >> > > > >> > > > > > > > > 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
> > <
> > > > >> > > > >> > > > [hidden email]
> > > > >> > > > >> > > > > > >:
> > > > >> > > > >> > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > 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 <
> > > > >> > > > >> > > > [hidden email]
> > > > >> > > > >> > > > > > >:
> > > > >> > > > >> > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > > Vladimir,
> > > > >> > > > >> > > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the
> near
> > > > >> future.
> > > > >> > > > >> > > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir
> > > Ozerov <
> > > > >> > > > >> > > > > > [hidden email]
> > > > >> > > > >> > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >
> > > > >> > > > >> > > > > > > > > > >> 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 <
> > > > >> > > > >> > > > > > > > > [hidden email]>
> > > > >> > > > >> > > > > > > > > > >> 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
> > > > >> <
> > > > >> > > > >> > > > > > > > [hidden email]
> > > > >> > > > >> > > > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> >
> > > > >> > > > >> > > > > > > > > > >> > > 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 <
> > > > >> > > > >> > > > > > > > > > >> [hidden email]>:
> > > > >> > > > >> > > > > > > > > > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> 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 <
> > > > >> > > > >> > > > > > > > [hidden email]
> > > > >> > > > >> > > > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >>
> > > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > >> > > > >> > > > > > > > > > >> [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > > >> > > > >> <
> > > > >> > > > >> > > > > > > > > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> >:
> > > > >> > > > >> > > > > > > > > > >> > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > >> > > > >> > > <
> > > > >> > > > >> > > > > > > > > > >> > >> [hidden email]>:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]>
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > >> > > > >> > > > > > > > <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello,
> > Alex.
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also
> > have
> > > > >> suspend
> > > > >> > > and
> > > > >> > > > >> > > resume
> > > > >> > > > >> > > > > > > > > operations.
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think
> we
> > > > >> should
> > > > >> > > > >> support them
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26
> > марта
> > > > >> 2019 г.,
> > > > >> > > > >> 22:07
> > > > >> > > > >> > > > Sergey
> > > > >> > > > >> > > > > > > > Kozlov
> > > > >> > > > >> > > > > > > > > <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > >> [hidden email]
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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
> > >
> > >
> >
>

[Igor Sapego-2]

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 <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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, Павлухин Иван <[hidden email]>:
> > >
> > > > 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 <[hidden email]
> >:
> > > > >
> > > > > 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 <[hidden email]
> >:
> > > > >
> > > > > > 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, Павлухин Иван <[hidden email]>:
> > > > > >
> > > > > >> 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 <
> > [hidden email]
> > > >:
> > > > > >> >
> > > > > >> > 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, Павлухин Иван <
> [hidden email]
> > >:
> > > > > >> >
> > > > > >> > > 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 <
> > > > [hidden email]>:
> > > > > >> > > >
> > > > > >> > > > 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 <
> > > > [hidden email]>:
> > > > > >> > > >
> > > > > >> > > > > 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, Павлухин Иван <
> > > > [hidden email]>:
> > > > > >> > > > >
> > > > > >> > > > >> Alex,
> > > > > >> > > > >>
> > > > > >> > > > >> Are you going to introduce settings specifying default
> > > values
> > > > > >> for tx
> > > > > >> > > > >> concurrency and isolation in client configuration?
> > > > > >> > > > >>
> > > > > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> > > > > >> [hidden email]>:
> > > > > >> > > > >> >
> > > > > >> > > > >> > 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 <
> > > > [hidden email]>:
> > > > > >> > > > >> >
> > > > > >> > > > >> > > 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 Павлухин Иван <
> > > > > >> > > [hidden email]>
> > > > > >> > > > >> 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 <
> > > > > >> [hidden email]>:
> > > > > >> > > > >> > > > >
> > > > > >> > > > >> > > > > 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
> <
> > > > > >> > > > >> > > [hidden email]>
> > > > > >> > > > >> > > > > 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 <
> > > > > >> [hidden email]
> > > > > >> > > >:
> > > > > >> > > > >> > > > > >
> > > > > >> > > > >> > > > > > > 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 <
> > > > > >> > > > >> > > > [hidden email]>
> > > > > >> > > > >> > > > > > > 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, Павлухин Иван
> <
> > > > > >> > > > >> [hidden email]>:
> > > > > >> > > > >> > > > > > > >
> > > > > >> > > > >> > > > > > > > > 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
> > > <
> > > > > >> > > > >> > > > [hidden email]
> > > > > >> > > > >> > > > > > >:
> > > > > >> > > > >> > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > 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 <
> > > > > >> > > > >> > > > [hidden email]
> > > > > >> > > > >> > > > > > >:
> > > > > >> > > > >> > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > > Vladimir,
> > > > > >> > > > >> > > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the
> > near
> > > > > >> future.
> > > > > >> > > > >> > > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14,
> Vladimir
> > > > Ozerov <
> > > > > >> > > > >> > > > > > [hidden email]
> > > > > >> > > > >> > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >
> > > > > >> > > > >> > > > > > > > > > >> 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 <
> > > > > >> > > > >> > > > > > > > > [hidden email]>
> > > > > >> > > > >> > > > > > > > > > >> 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
> > > > > >> <
> > > > > >> > > > >> > > > > > > > [hidden email]
> > > > > >> > > > >> > > > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> >
> > > > > >> > > > >> > > > > > > > > > >> > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> [hidden email]>:
> > > > > >> > > > >> > > > > > > > > > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> 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 <
> > > > > >> > > > >> > > > > > > > [hidden email]
> > > > > >> > > > >> > > > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >>
> > > > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > > >> > > > >> > > > > > > > > > >> [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > > > >> > > > >> <
> > > > > >> > > > >> > > > > > > > > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > > >> > > > >> > > <
> > > > > >> > > > >> > > > > > > > > > >> > >> [hidden email]>:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > >
> [hidden email]>
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > > >> > > > >> > > > > > > > <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > > [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello,
> > > Alex.
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We
> also
> > > have
> > > > > >> suspend
> > > > > >> > > and
> > > > > >> > > > >> > > resume
> > > > > >> > > > >> > > > > > > > > operations.
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I
> think
> > we
> > > > > >> should
> > > > > >> > > > >> support them
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26
> > > марта
> > > > > >> 2019 г.,
> > > > > >> > > > >> 22:07
> > > > > >> > > > >> > > > Sergey
> > > > > >> > > > >> > > > > > > > Kozlov
> > > > > >> > > > >> > > > > > > > > <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > >> [hidden email]
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >
> 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
> > > >
> > > >
> > >
> >
>

[Alexey Plekhanov]

Igor,

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

ср, 21 авг. 2019 г. в 17:59, Igor Sapego <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>:
> >
> > > 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 <
> [hidden email]>
> > > 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, Павлухин Иван <[hidden email]>:
> > > >
> > > > > 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 <
> [hidden email]
> > >:
> > > > > >
> > > > > > 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 <
> [hidden email]
> > >:
> > > > > >
> > > > > > > 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, Павлухин Иван <[hidden email]
> >:
> > > > > > >
> > > > > > >> 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 <
> > > [hidden email]
> > > > >:
> > > > > > >> >
> > > > > > >> > 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, Павлухин Иван <
> > [hidden email]
> > > >:
> > > > > > >> >
> > > > > > >> > > 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 <
> > > > > [hidden email]>:
> > > > > > >> > > >
> > > > > > >> > > > 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 <
> > > > > [hidden email]>:
> > > > > > >> > > >
> > > > > > >> > > > > 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, Павлухин Иван <
> > > > > [hidden email]>:
> > > > > > >> > > > >
> > > > > > >> > > > >> Alex,
> > > > > > >> > > > >>
> > > > > > >> > > > >> Are you going to introduce settings specifying
> default
> > > > values
> > > > > > >> for tx
> > > > > > >> > > > >> concurrency and isolation in client configuration?
> > > > > > >> > > > >>
> > > > > > >> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
> > > > > > >> [hidden email]>:
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > 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 <
> > > > > [hidden email]>:
> > > > > > >> > > > >> >
> > > > > > >> > > > >> > > 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 Павлухин Иван <
> > > > > > >> > > [hidden email]>
> > > > > > >> > > > >> 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 <
> > > > > > >> [hidden email]>:
> > > > > > >> > > > >> > > > >
> > > > > > >> > > > >> > > > > 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
> > <
> > > > > > >> > > > >> > > [hidden email]>
> > > > > > >> > > > >> > > > > 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 <
> > > > > > >> [hidden email]
> > > > > > >> > > >:
> > > > > > >> > > > >> > > > > >
> > > > > > >> > > > >> > > > > > > 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 <
> > > > > > >> > > > >> > > > [hidden email]>
> > > > > > >> > > > >> > > > > > > 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, Павлухин
> Иван
> > <
> > > > > > >> > > > >> [hidden email]>:
> > > > > > >> > > > >> > > > > > > >
> > > > > > >> > > > >> > > > > > > > > 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
> > > > <
> > > > > > >> > > > >> > > > [hidden email]
> > > > > > >> > > > >> > > > > > >:
> > > > > > >> > > > >> > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > 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 <
> > > > > > >> > > > >> > > > [hidden email]
> > > > > > >> > > > >> > > > > > >:
> > > > > > >> > > > >> > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > > Vladimir,
> > > > > > >> > > > >> > > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in
> the
> > > near
> > > > > > >> future.
> > > > > > >> > > > >> > > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14,
> > Vladimir
> > > > > Ozerov <
> > > > > > >> > > > >> > > > > > [hidden email]
> > > > > > >> > > > >> > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > >> 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 <
> > > > > > >> > > > >> > > > > > > > > [hidden email]>
> > > > > > >> > > > >> > > > > > > > > > >> 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
> > > > > > >> <
> > > > > > >> > > > >> > > > > > > > [hidden email]
> > > > > > >> > > > >> > > > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> >
> > > > > > >> > > > >> > > > > > > > > > >> > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> [hidden email]>:
> > > > > > >> > > > >> > > > > > > > > > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> 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 <
> > > > > > >> > > > >> > > > > > > > [hidden email]
> > > > > > >> > > > >> > > > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >>
> > > > > > >> > > > >> > > > > > > > > > >> > >> > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > 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
> > > > > > >> > > > >> <
> > > > > > >> > > > >> > > > > > > > > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > 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
> > > > > > >> > > > >> > > <
> > > > > > >> > > > >> > > > > > > > > > >> > >> [hidden email]>:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > >
> > [hidden email]>
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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
> > > > > > >> > > > >> > > > > > > > <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > >
> [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > > > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >
> > > > > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> Hello,
> > > > Alex.
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We
> > also
> > > > have
> > > > > > >> suspend
> > > > > > >> > > and
> > > > > > >> > > > >> > > resume
> > > > > > >> > > > >> > > > > > > > > operations.
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I
> > think
> > > we
> > > > > > >> should
> > > > > > >> > > > >> support them
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт,
> 26
> > > > марта
> > > > > > >> 2019 г.,
> > > > > > >> > > > >> 22:07
> > > > > > >> > > > >> > > > Sergey
> > > > > > >> > > > >> > > > > > > > Kozlov
> > > > > > >> > > > >> > > > > > > > > <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > >
> > [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > >:
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > 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 <
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
> > > > > > >> [hidden email]
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
> > > > > > >> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >
> > 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
> > > > >
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

Igor, Alex,

Not sure I agree with this: ThinClientConfiguration inside
ClientConnectorConfiguration.
Very confusing IMO, because ClientConnectorConfiguration is already related
to thin clients only.

Why not put the new property directly into ClientConnectorConfiguration?

[Alexey Plekhanov]

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

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

[Pavel Tupitsyn]

I think it is less confusing than  ThinClientConfiguration.

On Fri, Aug 23, 2019 at 8:49 PM Alex Plehanov <[hidden email]>
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 <[hidden email]>:
>
> > 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?
> >
>

[Ilya Kasnacheev]

Hello!

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

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

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

Regards,
--
Ilya Kasnacheev


пт, 23 авг. 2019 г. в 20:49, Alex Plehanov <[hidden email]>:

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

[Ilya Kasnacheev]

Hello!

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

Regards,
--
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 12:27, Ilya Kasnacheev <[hidden email]>:

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

[Igor Sapego-2]

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

[Ilya Kasnacheev]

Hello!

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

Regards,
--
Ilya Kasnacheev


пн, 26 авг. 2019 г. в 14:16, Igor Sapego <[hidden email]>:

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

[Igor Sapego-2]

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

[Ilya Kasnacheev]

Hello!

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

Regards,
--
Ilya Kasnacheev


вт, 27 авг. 2019 г. в 15:06, Igor Sapego <[hidden email]>:

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

[Alexey Plekhanov]

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

> Hello!
>
> I think the nested property approach is correct. Sorry for causing the
> confusion.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 27 авг. 2019 г. в 15:06, Igor Sapego <[hidden email]>:
>
> > 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 <
> > [hidden email]>
> > 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 <[hidden email]>:
> > >
> > > > 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 <
> > > > [hidden email]>
> > > > 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 <
> > > [hidden email]
> > > > >:
> > > > >
> > > > > > 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 <
> > [hidden email]
> > > >:
> > > > > >
> > > > > >> 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 <
> [hidden email]
> > >:
> > > > > >>
> > > > > >> > 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?
> > > > > >> >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

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

On Tue, Aug 27, 2019 at 5:07 PM Alex Plehanov <[hidden email]>
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 <[hidden email]>:
>
> > Hello!
> >
> > I think the nested property approach is correct. Sorry for causing the
> > confusion.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > вт, 27 авг. 2019 г. в 15:06, Igor Sapego <[hidden email]>:
> >
> > > 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 <
> > > [hidden email]>
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > > > [hidden email]>
> > > > > 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 <
> > > > [hidden email]
> > > > > >:
> > > > > >
> > > > > > > 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 <
> > > [hidden email]
> > > > >:
> > > > > > >
> > > > > > >> 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 <
> > [hidden email]
> > > >:
> > > > > > >>
> > > > > > >> > 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?
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Alexey Plekhanov]

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

> 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 <[hidden email]>
> 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 <[hidden email]
> >:
> >
> > > Hello!
> > >
> > > I think the nested property approach is correct. Sorry for causing the
> > > confusion.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > вт, 27 авг. 2019 г. в 15:06, Igor Sapego <[hidden email]>:
> > >
> > > > 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 <
> > > > [hidden email]>
> > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > 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 <
> > > > > [hidden email]
> > > > > > >:
> > > > > > >
> > > > > > > > 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 <
> > > > [hidden email]
> > > > > >:
> > > > > > > >
> > > > > > > >> 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 <
> > > [hidden email]
> > > > >:
> > > > > > > >>
> > > > > > > >> > 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?
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Pavel Tupitsyn]

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

On Wed, Aug 28, 2019 at 12:59 PM Alex Plehanov <[hidden email]>
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <
> [hidden email]
> > >:
> > >
> > > > Hello!
> > > >
> > > > I think the nested property approach is correct. Sorry for causing
> the
> > > > confusion.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > вт, 27 авг. 2019 г. в 15:06, Igor Sapego <[hidden email]>:
> > > >
> > > > > 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 <
> > > > > [hidden email]>
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > 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 <
> > > > > > > [hidden email]>
> > > > > > > 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 <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > > >
> > > > > > > > > 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 <
> > > > > [hidden email]
> > > > > > >:
> > > > > > > > >
> > > > > > > > >> 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 <
> > > > [hidden email]
> > > > > >:
> > > > > > > > >>
> > > > > > > > >> > 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?
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>