ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Plehanov <plehanov.a...@gmail.com>
Subject Re: Thin client: transactions support
Date Wed, 14 Aug 2019 10:58:46 GMT
Hi Igniters,

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

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

пн, 27 мая 2019 г. в 13:27, Alex Plehanov <plehanov.alex@gmail.com>:

> Ivan,
>
> Yes, .NET client has such capability. Pavel Tupitsyn already mentions it
> in this thread. As far as I understand, in .NET client implementation to
> dispatch responses dedicated thread is used.
> In a draft implementation of IGNITE-11685 I've used another approach: each
> request thread can read a response (if lock is acquired by this thread
> successfully) and complete a future of its own request or another threads
> request.
>
> пн, 27 мая 2019 г. в 13:01, Павлухин Иван <vololo100@gmail.com>:
>
>> Alex,
>>
>> I am quite curious about async implementations from other clients. Is
>> there any design document describing such implementations? Does .NET
>> client have such capability?
>>
>> Actually, I forgot to finish my previous message. One of my concerns
>> is that a concurrent response dispatch does not sound as a trivial
>> thing. So, I would like to understand if we already have a good
>> approach for that. If not then I suppose it worth a discussion.
>>
>> пн, 27 мая 2019 г. в 12:51, Alex Plehanov <plehanov.alex@gmail.com>:
>> >
>> > Hi Ivan.
>> >
>> > Thin client transactions support is not only for java thin client. There
>> > are other clients, some of them already work in async mode.
>> > Ticket IGNITE-11685 already has draft implementation too, but now it's
>> > based on some changes to java thin client which were made by
>> "transaction
>> > support" implementation. I think this ticket will be ready in a couple
>> of
>> > days after "transaction support" will be merged. And both patches will
>> be
>> > included in the same release.
>> >
>> > пн, 27 мая 2019 г. в 11:57, Павлухин Иван <vololo100@gmail.com>:
>> >
>> > > Hi Alex,
>> > >
>> > > Regarding a problem with possible deadlock when two concurrent
>> > > transactions from the same client are trying to lock the same key and
>> > > an issue [1]. It seems to me that without fixing the issue [1] a
>> > > client transactions feature is not practical. Everyone who uses a
>> > > client from multiple threads can face a deadlock which is impossible
>> > > to deal with. Or am I missing something here?
>> > >
>> > > One workaround I can imagine is failing a transactions execution from
>> > > concurrent threads for a first time.
>> > >
>> > > [1] https://issues.apache.org/jira/browse/IGNITE-11685
>> > >
>> > > вт, 21 мая 2019 г. в 19:05, Alex Plehanov <plehanov.alex@gmail.com>:
>> > > >
>> > > > Guys,
>> > > >
>> > > > I've updated the IEP [1]. Please have a look.
>> > > >
>> > > > [1]
>> > > >
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > > >
>> > > >
>> > > > вт, 21 мая 2019 г., 14:19 Alex Plehanov <plehanov.alex@gmail.com>:
>> > > >
>> > > > > Ivan,
>> > > > >
>> > > > > Yes, I have plans to do that (at least for java thin client).
>> Something
>> > > > > like new class "ClientTransactionConfiguration" inside
>> > > > > "ClientConfiguration".
>> > > > >
>> > > > > вт, 21 мая 2019 г. в 13:37, Павлухин Иван <vololo100@gmail.com>:
>> > > > >
>> > > > >> Alex,
>> > > > >>
>> > > > >> Are you going to introduce settings specifying default values
>> for tx
>> > > > >> concurrency and isolation in client configuration?
>> > > > >>
>> > > > >> пн, 20 мая 2019 г. в 19:34, Alex Plehanov <
>> plehanov.alex@gmail.com>:
>> > > > >> >
>> > > > >> > Igor,
>> > > > >> >
>> > > > >> > Perhaps we don't really need to use server's default values
>> for tx
>> > > > >> > parameters. It's a minor fix and can be easily implemented if
>> it
>> > > will be
>> > > > >> > required in the future.
>> > > > >> > I will update IEP tomorrow regarding point 1 and point 3.
>> > > > >> > Thanks for your feedback.
>> > > > >> >
>> > > > >> > пн, 20 мая 2019 г. в 15:24, Igor Sapego <isapego@apache.org>:
>> > > > >> >
>> > > > >> > > Ivan,
>> > > > >> > >
>> > > > >> > > This may be a good point for a DBMS, but Ignite is much more
>> than
>> > > > >> just a
>> > > > >> > > DBMS and Ignite client code is not just an SQL query (which
>> > > execution
>> > > > >> > > inherently heavily depends on DBMS). With database user is
>> > > expecting
>> > > > >> that
>> > > > >> > > server have a lot of control on query execution. But with
>> Ignite,
>> > > in
>> > > > >> my
>> > > > >> > > opinion,
>> > > > >> > > user writes generic code including business logic in native
>> > > language
>> > > > >> and
>> > > > >> > > may
>> > > > >> > > expect more deterministic behaviour from a client.
>> > > > >> > >
>> > > > >> > > Also, thick clients do not use server-side defaults.
>> > > > >> > >
>> > > > >> > > Of course, this question is debatable and It's not like I
>> 100%
>> > > against
>> > > > >> > > server-side
>> > > > >> > > defaults here, I just suggest to discuss it in more detail.
>> > > > >> > >
>> > > > >> > > Best Regards,
>> > > > >> > > Igor
>> > > > >> > >
>> > > > >> > >
>> > > > >> > > On Mon, May 20, 2019 at 2:21 PM Павлухин Иван <
>> > > vololo100@gmail.com>
>> > > > >> wrote:
>> > > > >> > >
>> > > > >> > > > Igor, Alex,
>> > > > >> > > >
>> > > > >> > > > Regarding point 1. I must say that SQL vendors usually
>> allow to
>> > > > >> > > > configure default timeouts and a transaction isolation on a
>> > > server
>> > > > >> > > > side. E.g. in MySQL you can do a following:
>> > > > >> > > > set local tx_isolation = <isolation> -- per SQL client
>> session
>> > > > >> > > > (usually physical network connection)
>> > > > >> > > > set global tx_isolation = <isolation> -- global settings,
>> all
>> > > > >> clients
>> > > > >> > > > (which does not override it) are affected
>> > > > >> > > >
>> > > > >> > > > So, if it is a standard practice why should do it
>> differently?
>> > > If it
>> > > > >> > > > is not, we can continue discussion. Do we have some
>> examples
>> > > > >> following
>> > > > >> > > > opposite way (client-wide default setting)?
>> > > > >> > > >
>> > > > >> > > > пн, 20 мая 2019 г. в 13:50, Igor Sapego <
>> isapego@apache.org>:
>> > > > >> > > > >
>> > > > >> > > > > 1. In my opinion, having client-specific transaction
>> > > parameters is
>> > > > >> > > > expected
>> > > > >> > > > > for
>> > > > >> > > > > client when have different arguments depending on server
>> seems
>> > > > >> > > unexpected
>> > > > >> > > > > and can lead to hard-to-debug bugs and issues when
>> updating
>> > > from
>> > > > >> old to
>> > > > >> > > > new
>> > > > >> > > > > server versions. Also it goes against common practice
>> with
>> > > > >> arguments of
>> > > > >> > > > thin
>> > > > >> > > > > client and thus, may be even more unexpected.
>> > > > >> > > > >
>> > > > >> > > > > I believe that if we want to add ability to client to
>> adopt
>> > > some
>> > > > >> > > server's
>> > > > >> > > > > defaults
>> > > > >> > > > > we should implement it as separate feature, and it
>> should not
>> > > be a
>> > > > >> > > > default
>> > > > >> > > > > behaviour for client, user should explicitly state that
>> they
>> > > want
>> > > > >> this
>> > > > >> > > > > behaviour,
>> > > > >> > > > > so it won't be unexpected for them.
>> > > > >> > > > >
>> > > > >> > > > > 3. "Flags" field looks like a good solution to me.
>> > > > >> > > > >
>> > > > >> > > > > Best Regards,
>> > > > >> > > > > Igor
>> > > > >> > > > >
>> > > > >> > > > >
>> > > > >> > > > > On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <
>> > > > >> > > plehanov.alex@gmail.com>
>> > > > >> > > > > wrote:
>> > > > >> > > > >
>> > > > >> > > > > > Hi, Igor
>> > > > >> > > > > >
>> > > > >> > > > > > 1. I think it's better to have the ability to configure
>> > > > >> transaction
>> > > > >> > > > > > parameters (for example configure default timeout for
>> all
>> > > > >> clients) on
>> > > > >> > > > > > server-side, then don't have such ability and always
>> use
>> > > some
>> > > > >> > > > predefined
>> > > > >> > > > > > client-side values (which can be different for
>> different
>> > > client
>> > > > >> > > > > > implementations). At least default timeout is more
>> server
>> > > > >> specific
>> > > > >> > > then
>> > > > >> > > > > > client specific parameter since it can affect
>> server-side
>> > > > >> processes
>> > > > >> > > > (PME
>> > > > >> > > > > > for example).
>> > > > >> > > > > >
>> > > > >> > > > > > 2. IgniteUuid has 24 bytes length. This tx id needs to
>> be
>> > > > >> included to
>> > > > >> > > > each
>> > > > >> > > > > > cache operation under a transaction. And it almost
>> will not
>> > > > >> simplify
>> > > > >> > > > server
>> > > > >> > > > > > code. Also, thin clients don't know how to deal with
>> > > IgniteUuid
>> > > > >> now,
>> > > > >> > > > there
>> > > > >> > > > > > is no such entity in the protocol, there are no
>> described
>> > > rules
>> > > > >> on
>> > > > >> > > how
>> > > > >> > > > to
>> > > > >> > > > > > convert it to a string. For monitoring/debugging
>> purposes we
>> > > > >> should
>> > > > >> > > > have
>> > > > >> > > > > > the same presentation of this entity on server and
>> client
>> > > > >> sides. I
>> > > > >> > > > think if
>> > > > >> > > > > > we need to know real tx id on the client side it's
>> better to
>> > > > >> > > > additionally
>> > > > >> > > > > > include this value to OP_TX_START response (we also can
>> > > > >> serialize it
>> > > > >> > > > as a
>> > > > >> > > > > > string to avoid introducing new entity on client side)
>> or
>> > > > >> create a
>> > > > >> > > new
>> > > > >> > > > > > operation to explicitly request tx id (for example
>> > > OP_TX_INFO).
>> > > > >> > > > > >
>> > > > >> > > > > > 3. Make sense, we can reuse deprecated "flags" field
>> > > > >> (undeprecate
>> > > > >> > > it),
>> > > > >> > > > > > which is included now to each cache operation.
>> > > > >> > > > > >
>> > > > >> > > > > >
>> > > > >> > > > > > пт, 17 мая 2019 г. в 18:49, Igor Sapego <
>> isapego@apache.org
>> > > >:
>> > > > >> > > > > >
>> > > > >> > > > > > > Hi,
>> > > > >> > > > > > >
>> > > > >> > > > > > > I had a look at IEP and have several comments:
>> > > > >> > > > > > >
>> > > > >> > > > > > > 1. Why would one want to use to use server's default
>> > > values
>> > > > >> for
>> > > > >> > > > > > Concurrency
>> > > > >> > > > > > > or Isolation?
>> > > > >> > > > > > > I believe, client should have its own defaults which
>> > > should be
>> > > > >> > > > explicitly
>> > > > >> > > > > > > documented, so that
>> > > > >> > > > > > > behaviour of transactions will not depend on the
>> server
>> > > node
>> > > > >> it was
>> > > > >> > > > > > routed
>> > > > >> > > > > > > to. The same goes
>> > > > >> > > > > > > for timeout.
>> > > > >> > > > > > >
>> > > > >> > > > > > > 2. Not sure about transaction ID represented by int.
>> Why
>> > > not
>> > > > >> to use
>> > > > >> > > > > > > IgniteUuid? It should simplify
>> > > > >> > > > > > > server code. Also it may help with
>> monitoring/debugging if
>> > > > >> thin
>> > > > >> > > > clients
>> > > > >> > > > > > and
>> > > > >> > > > > > > server nodes use the
>> > > > >> > > > > > > same identifier for transactions. It does not seem
>> as a
>> > > big
>> > > > >> > > overhead
>> > > > >> > > > to
>> > > > >> > > > > > me
>> > > > >> > > > > > > either.
>> > > > >> > > > > > >
>> > > > >> > > > > > > 3. Maybe it makes sense to add "In transaction"
>> boolean
>> > > flag
>> > > > >> to
>> > > > >> > > cache
>> > > > >> > > > > > > operation request header
>> > > > >> > > > > > > to avoid bloating message size in non-affected
>> scenarios.
>> > > > >> > > > > > >
>> > > > >> > > > > > > Best Regards,
>> > > > >> > > > > > > Igor
>> > > > >> > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > > > On Mon, May 13, 2019 at 1:58 PM Alex Plehanov <
>> > > > >> > > > plehanov.alex@gmail.com>
>> > > > >> > > > > > > wrote:
>> > > > >> > > > > > >
>> > > > >> > > > > > > > Hi, Ivan.
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > Thanks for your comments.
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > 1. Transaction id in thin client protocol it's
>> just a tx
>> > > > >> counter
>> > > > >> > > > for
>> > > > >> > > > > > the
>> > > > >> > > > > > > > current connection. It's not related to
>> > > GridCacheVersion.
>> > > > >> If we
>> > > > >> > > > want to
>> > > > >> > > > > > > > know GridCacheVersion on the client side, I think
>> we
>> > > should
>> > > > >> > > > introduce a
>> > > > >> > > > > > > new
>> > > > >> > > > > > > > type of operation (for example OP_TX_INFO).
>> > > > >> > > > > > > > 2. Error handling is already provided by thin
>> client
>> > > > >> protocol,
>> > > > >> > > > even in
>> > > > >> > > > > > > case
>> > > > >> > > > > > > > of empty response. Of course, the client will know
>> if
>> > > there
>> > > > >> is a
>> > > > >> > > > > > failure
>> > > > >> > > > > > > > occurred during OP_TX_END operation.
>> > > > >> > > > > > > > 3. AFAIK some of thin client implementations
>> already
>> > > send
>> > > > >> > > requests
>> > > > >> > > > and
>> > > > >> > > > > > > > process responses in an async way (.NET for
>> example). As
>> > > > >> for java
>> > > > >> > > > thin
>> > > > >> > > > > > > > client, in the current implementation channel is
>> locked
>> > > > >> > > exclusively
>> > > > >> > > > > > > before
>> > > > >> > > > > > > > request send and until the response is processed.
>> I have
>> > > > >> some
>> > > > >> > > ideas
>> > > > >> > > > > > about
>> > > > >> > > > > > > > how to fix this (split send/receive process into
>> two
>> > > > >> different
>> > > > >> > > > parts
>> > > > >> > > > > > and
>> > > > >> > > > > > > > acquire locks for this parts separately or create
>> > > futures on
>> > > > >> > > > request
>> > > > >> > > > > > sent
>> > > > >> > > > > > > > and complete it after processing the response in a
>> > > dedicated
>> > > > >> > > > thread),
>> > > > >> > > > > > > I've
>> > > > >> > > > > > > > created ticket [1] for this issue and will try to
>> > > implement
>> > > > >> > > > prototype
>> > > > >> > > > > > in
>> > > > >> > > > > > > a
>> > > > >> > > > > > > > couple of days.
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > About suspend/resume, yes, on server-side we should
>> > > resume
>> > > > >> tx
>> > > > >> > > > before
>> > > > >> > > > > > each
>> > > > >> > > > > > > > transactional cache operation and suspend the tx
>> after
>> > > the
>> > > > >> > > > operation.
>> > > > >> > > > > > In
>> > > > >> > > > > > > my
>> > > > >> > > > > > > > opinion, suspend/resume approach have several
>> advantages
>> > > > >> over
>> > > > >> > > > approach
>> > > > >> > > > > > > with
>> > > > >> > > > > > > > explicit tx id argument:
>> > > > >> > > > > > > > - Introducing explicit tx id argument for cache
>> > > operations
>> > > > >> leads
>> > > > >> > > > to a
>> > > > >> > > > > > > > significant API change
>> > > > >> > > > > > > > - It's not clear how to use it together with
>> current
>> > > > >> > > > (tx-per-thread)
>> > > > >> > > > > > > > approach (for example, what if a thread is already
>> held
>> > > > >> > > > transaction and
>> > > > >> > > > > > > > someone call cache operation with explicit tx id?)
>> > > > >> > > > > > > > - Suspend/resume feature will also be useful for
>> thick
>> > > > >> clients
>> > > > >> > > > > > > > - Suspend/resume functionality is already partially
>> > > > >> implemented
>> > > > >> > > > (for
>> > > > >> > > > > > > > optimistic transactions only)
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > [1]
>> https://issues.apache.org/jira/browse/IGNITE-11685
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > пт, 3 мая 2019 г. в 08:10, Павлухин Иван <
>> > > > >> vololo100@gmail.com>:
>> > > > >> > > > > > > >
>> > > > >> > > > > > > > > Hi Alex,
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > I went through IEP [1] and I have a couple of
>> > > questions:
>> > > > >> > > > > > > > > 1. What is going to be used as transaction id?
>> In a
>> > > > >> described
>> > > > >> > > > > > protocol
>> > > > >> > > > > > > > > I see an int field for it. Should not it be
>> > > > >> GridCacheVersion
>> > > > >> > > > > > > > > corresponding to IgniteInternalTx#xidVersion?
>> > > > >> > > > > > > > > 2. OP_TX_END message assumes an empty response,
>> but I
>> > > > >> think
>> > > > >> > > that
>> > > > >> > > > > > > > > errors during tx finish are possible and should
>> be
>> > > > >> returned in
>> > > > >> > > a
>> > > > >> > > > > > > > > response.
>> > > > >> > > > > > > > > 3. In IEP it is stated that async processing of
>> lock
>> > > > >> operations
>> > > > >> > > > > > should
>> > > > >> > > > > > > > > be introduced on a client side to enable
>> concurrent
>> > > > >> operations
>> > > > >> > > > from
>> > > > >> > > > > > > > > different client threads. Do you have an idea
>> how to
>> > > > >> achieve
>> > > > >> > > it?
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > Also, a bit about a suspend/resume trait. I
>> tried to
>> > > think
>> > > > >> > > about
>> > > > >> > > > it
>> > > > >> > > > > > > > > leaving away an existing transactions
>> implementation
>> > > in
>> > > > >> Ignite.
>> > > > >> > > > As I
>> > > > >> > > > > > > > > understood we are going to resume a tx before
>> each
>> > > cache
>> > > > >> > > > operation in
>> > > > >> > > > > > > > > the tx and resume the tx after the operation. All
>> > > this to
>> > > > >> make
>> > > > >> > > an
>> > > > >> > > > > > > > > executing thread available for other operations
>> (e.g.
>> > > in
>> > > > >> other
>> > > > >> > > > txs).
>> > > > >> > > > > > > > > From the first glance it seems like an inversed
>> > > logic. A
>> > > > >> > > > > > > > > straightforward way is to execute a cache
>> operation
>> > > > >> within a
>> > > > >> > > > > > > > > particular transaction defined as an explicit tx
>> id
>> > > > >> argument
>> > > > >> > > > (e.g.
>> > > > >> > > > > > > > > cache.put(key, value, txid)). Can we do so?
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > And leaving for now thin client API. I cannot say
>> > > that one
>> > > > >> > > > proposed
>> > > > >> > > > > > in
>> > > > >> > > > > > > > > IEP is good or bad. I can only say that it
>> ressembles
>> > > > >> current
>> > > > >> > > > thick
>> > > > >> > > > > > > > > client API. And perhaps it should not. I think
>> that we
>> > > > >> should
>> > > > >> > > > > > consider
>> > > > >> > > > > > > > > similar APIs provided by other vendors and keep
>> in
>> > > mind
>> > > > >> that we
>> > > > >> > > > have
>> > > > >> > > > > > a
>> > > > >> > > > > > > > > bunch of client implementations for different
>> > > languages. I
>> > > > >> > > > suppose
>> > > > >> > > > > > > > > that we can return to it a little bit later. And
>> I
>> > > hope
>> > > > >> that we
>> > > > >> > > > will
>> > > > >> > > > > > > > > do it.
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > [1]
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > >
>> > > > >> > >
>> > > > >>
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > > > вт, 30 апр. 2019 г. в 13:24, Alex Plehanov <
>> > > > >> > > > plehanov.alex@gmail.com
>> > > > >> > > > > > >:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > Hello, Igniters!
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > I've update IEP [1] and implement PoC
>> according to
>> > > new
>> > > > >> > > approach
>> > > > >> > > > > > > > (multiple
>> > > > >> > > > > > > > > > concurrent transactions per connection).
>> > > > >> > > > > > > > > > But to move forward another feature need to be
>> > > > >> implemented:
>> > > > >> > > > > > > > > suspend/resume
>> > > > >> > > > > > > > > > for pessimistic transactions (IGNITE-5714 [2]).
>> > > > >> > > Implementation
>> > > > >> > > > of
>> > > > >> > > > > > > > > > suspend/resume is ready now and ticket in
>> 'Patch
>> > > > >> available'
>> > > > >> > > > status.
>> > > > >> > > > > > > Can
>> > > > >> > > > > > > > > any
>> > > > >> > > > > > > > > > transactions expert help with review of
>> IGNITE-5714?
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > [1]:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > >
>> > > > >> > >
>> > > > >>
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > > > >> > > > > > > > > > [2]:
>> > > https://issues.apache.org/jira/browse/IGNITE-5714
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > чт, 4 апр. 2019 г. в 11:32, Alex Plehanov <
>> > > > >> > > > plehanov.alex@gmail.com
>> > > > >> > > > > > >:
>> > > > >> > > > > > > > > >
>> > > > >> > > > > > > > > > > Vladimir,
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > Ok, then I will rewrite IEP in the near
>> future.
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <
>> > > > >> > > > > > vozerov@gridgain.com
>> > > > >> > > > > > > >:
>> > > > >> > > > > > > > > > >
>> > > > >> > > > > > > > > > >> Hi Alex,
>> > > > >> > > > > > > > > > >>
>> > > > >> > > > > > > > > > >> I think we should be able to handle many
>> > > transactions
>> > > > >> > > > through a
>> > > > >> > > > > > > > single
>> > > > >> > > > > > > > > > >> connection. This will make our protocol and
>> > > client
>> > > > >> > > > > > implementations
>> > > > >> > > > > > > > > much
>> > > > >> > > > > > > > > > >> more efficient, and simplicity from
>> developer's
>> > > > >> > > perspective
>> > > > >> > > > is
>> > > > >> > > > > > not
>> > > > >> > > > > > > > our
>> > > > >> > > > > > > > > > >> goal. Consider normal nodes. We have server
>> > > nodes and
>> > > > >> > > client
>> > > > >> > > > > > > nodes.
>> > > > >> > > > > > > > > You
>> > > > >> > > > > > > > > > >> may
>> > > > >> > > > > > > > > > >> span whatever number of transactions you
>> need,
>> > > but
>> > > > >> all of
>> > > > >> > > > them
>> > > > >> > > > > > are
>> > > > >> > > > > > > > > > >> coordinated through a single connection.
>> The same
>> > > > >> should
>> > > > >> > > be
>> > > > >> > > > > > > > > applicable to
>> > > > >> > > > > > > > > > >> thin clients. Protocol is already designed
>> to
>> > > handle
>> > > > >> this,
>> > > > >> > > > as we
>> > > > >> > > > > > > > pass
>> > > > >> > > > > > > > > > >> unique operation ID in order to distinguish
>> one
>> > > > >> operation
>> > > > >> > > > from
>> > > > >> > > > > > > > > another. It
>> > > > >> > > > > > > > > > >> is true, though, that we will have to
>> introduce a
>> > > > >> kind of
>> > > > >> > > > > > > "session"
>> > > > >> > > > > > > > > > >> concept, and pass additional identifier
>> along
>> > > with
>> > > > >> cache
>> > > > >> > > > > > > operations,
>> > > > >> > > > > > > > > but
>> > > > >> > > > > > > > > > >> this doesn't sound like a problem to me.
>> > > > >> > > > > > > > > > >>
>> > > > >> > > > > > > > > > >> And provided that currently server-side
>> > > transactions
>> > > > >> are
>> > > > >> > > > bound
>> > > > >> > > > > > to
>> > > > >> > > > > > > > > threads
>> > > > >> > > > > > > > > > >> artificially, I would say that the first
>> step in
>> > > > >> > > > implementation
>> > > > >> > > > > > of
>> > > > >> > > > > > > > > > >> transactions on thin clients should be
>> decoupling
>> > > > >> > > > server-side
>> > > > >> > > > > > > > > transactions
>> > > > >> > > > > > > > > > >> from threads. Without this we will have very
>> > > > >> inefficient
>> > > > >> > > > > > > > > implementation,
>> > > > >> > > > > > > > > > >> when every new client transaction have to
>> spawn
>> > > a new
>> > > > >> > > > thread.
>> > > > >> > > > > > This
>> > > > >> > > > > > > > is
>> > > > >> > > > > > > > > slow
>> > > > >> > > > > > > > > > >> and introduces high memory pressure on a
>> cluster
>> > > > >> node. We
>> > > > >> > > > > > already
>> > > > >> > > > > > > > work
>> > > > >> > > > > > > > > > >> this
>> > > > >> > > > > > > > > > >> way for MVCC transactions which are spawned
>> from
>> > > JDBC
>> > > > >> > > > driver,
>> > > > >> > > > > > and
>> > > > >> > > > > > > > > believe
>> > > > >> > > > > > > > > > >> me, we do not want to replicated this bad
>> > > practice to
>> > > > >> > > other
>> > > > >> > > > > > > clients
>> > > > >> > > > > > > > > :-)
>> > > > >> > > > > > > > > > >>
>> > > > >> > > > > > > > > > >> Vladimir.
>> > > > >> > > > > > > > > > >>
>> > > > >> > > > > > > > > > >> On Thu, Apr 4, 2019 at 10:08 AM Alex
>> Plehanov <
>> > > > >> > > > > > > > > plehanov.alex@gmail.com>
>> > > > >> > > > > > > > > > >> wrote:
>> > > > >> > > > > > > > > > >>
>> > > > >> > > > > > > > > > >> > Guys, so, do we need multiple concurrent
>> > > > >> transactions
>> > > > >> > > per
>> > > > >> > > > > > > > > connection?
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > There are pros and cons for each approach.
>> > > > >> Difference
>> > > > >> > > > between
>> > > > >> > > > > > > > > > >> approaches:
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > One transaction at a time per connection:
>> > > > >> > > > > > > > > > >> >  - This approach is used in RDBMS world
>> and
>> > > users
>> > > > >> got
>> > > > >> > > > used to
>> > > > >> > > > > > it
>> > > > >> > > > > > > > > > >> >  - To use transactions concurrently users
>> need
>> > > to
>> > > > >> use
>> > > > >> > > > > > different
>> > > > >> > > > > > > > > > >> connections
>> > > > >> > > > > > > > > > >> > and get these connections via something
>> like a
>> > > > >> > > connection
>> > > > >> > > > pool
>> > > > >> > > > > > > > > > >> >  - Easy to implement (in fact, PoC is
>> already
>> > > done)
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > Multiple concurrent transactions per
>> > > connection:
>> > > > >> > > > > > > > > > >> >  - At least for java thin client, we can
>> > > implement
>> > > > >> > > > transaction
>> > > > >> > > > > > > per
>> > > > >> > > > > > > > > > >> thread
>> > > > >> > > > > > > > > > >> > approach as implemented now for the thick
>> > > client
>> > > > >> > > (perhaps
>> > > > >> > > > > > other
>> > > > >> > > > > > > > thin
>> > > > >> > > > > > > > > > >> > clients can implement the same
>> abstraction)
>> > > > >> > > > > > > > > > >> >  - There is also protocol change for all
>> cache
>> > > > >> > > operations
>> > > > >> > > > > > needed
>> > > > >> > > > > > > > (to
>> > > > >> > > > > > > > > > >> bind
>> > > > >> > > > > > > > > > >> > cache operation to the transaction)
>> > > > >> > > > > > > > > > >> >  - Significant changes to all implemented
>> > > clients
>> > > > >> are
>> > > > >> > > > needed
>> > > > >> > > > > > > > > > >> >  - Implementation on the server side is
>> more
>> > > > >> complex
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > What do you think?
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov
>> <
>> > > > >> > > > > > > > plehanov.alex@gmail.com
>> > > > >> > > > > > > > > >:
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > > Ilya,
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > > > We should be able to multiplex several
>> > > > >> transactions
>> > > > >> > > > using
>> > > > >> > > > > > a
>> > > > >> > > > > > > > > single
>> > > > >> > > > > > > > > > >> > > Client connection.
>> > > > >> > > > > > > > > > >> > > In this case, we should significantly
>> change
>> > > > >> cache
>> > > > >> > > > > > operations
>> > > > >> > > > > > > > > syntax
>> > > > >> > > > > > > > > > >> (for
>> > > > >> > > > > > > > > > >> > > each implemented client), to bind each
>> > > operation
>> > > > >> to
>> > > > >> > > the
>> > > > >> > > > > > > > > transaction.
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > > > I want to also ask if "Number of
>> entries
>> > > > >> > > > participating in
>> > > > >> > > > > > > > > > >> transaction
>> > > > >> > > > > > > > > > >> > > (may be approximate). 0 - default
>> value." is
>> > > > >> needed.
>> > > > >> > > > > > > > > > >> > > I've tried to minimize API changes
>> between
>> > > thick
>> > > > >> and
>> > > > >> > > > thin
>> > > > >> > > > > > > client
>> > > > >> > > > > > > > > to
>> > > > >> > > > > > > > > > >> > > simplify move from one to another. It's
>> the
>> > > only
>> > > > >> > > reason.
>> > > > >> > > > > > But I
>> > > > >> > > > > > > > > agree
>> > > > >> > > > > > > > > > >> with
>> > > > >> > > > > > > > > > >> > > you, the parameter is not very useful.
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > > вт, 2 апр. 2019 г. в 14:48, Ilya
>> Kasnacheev <
>> > > > >> > > > > > > > > > >> ilya.kasnacheev@gmail.com>:
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> Hello!
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> Pavel, I agree with you thorougly. We
>> > > should be
>> > > > >> able
>> > > > >> > > to
>> > > > >> > > > > > > > multiplex
>> > > > >> > > > > > > > > > >> > several
>> > > > >> > > > > > > > > > >> > >> transactions using a single Client
>> > > connection.
>> > > > >> This
>> > > > >> > > > means
>> > > > >> > > > > > > > adding
>> > > > >> > > > > > > > > > >> > >> Transaction id parameter to every
>> affected
>> > > cache
>> > > > >> > > > operation
>> > > > >> > > > > > /
>> > > > >> > > > > > > > SQL
>> > > > >> > > > > > > > > > >> > statement
>> > > > >> > > > > > > > > > >> > >> (if applicable) to make sure we do
>> cache
>> > > > >> operations
>> > > > >> > > on
>> > > > >> > > > > > > relevant
>> > > > >> > > > > > > > > > >> > >> transaction.
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> This is how other things work in
>> Ignite,
>> > > such as
>> > > > >> > > > > > > communication.
>> > > > >> > > > > > > > > We do
>> > > > >> > > > > > > > > > >> > not
>> > > > >> > > > > > > > > > >> > >> open dozens of connections, we
>> multiplex
>> > > > >> operations
>> > > > >> > > > > > > > > asynchronously
>> > > > >> > > > > > > > > > >> > through
>> > > > >> > > > > > > > > > >> > >> a single connection.
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> I think that trying to pool Ignite
>> > > connections
>> > > > >> will
>> > > > >> > > be
>> > > > >> > > > > > highly
>> > > > >> > > > > > > > > > >> > >> inconvenient,
>> > > > >> > > > > > > > > > >> > >> since there is no existing
>> infrastructure
>> > > for
>> > > > >> such
>> > > > >> > > > pooling
>> > > > >> > > > > > > > (like
>> > > > >> > > > > > > > > > >> there
>> > > > >> > > > > > > > > > >> > >> exists for JDBC).
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> I want to also ask if "Number of
>> entries
>> > > > >> > > participating
>> > > > >> > > > in
>> > > > >> > > > > > > > > transaction
>> > > > >> > > > > > > > > > >> > (may
>> > > > >> > > > > > > > > > >> > >> be approximate). 0 - default value." is
>> > > needed.
>> > > > >> Does
>> > > > >> > > it
>> > > > >> > > > > > > > actually
>> > > > >> > > > > > > > > do
>> > > > >> > > > > > > > > > >> > >> anything in our tx protocol? Users of
>> > > existing
>> > > > >> APIs
>> > > > >> > > are
>> > > > >> > > > > > > already
>> > > > >> > > > > > > > > > >> confused
>> > > > >> > > > > > > > > > >> > >> by
>> > > > >> > > > > > > > > > >> > >> this parameter, if we could get rid of
>> it in
>> > > > >> thin
>> > > > >> > > > client
>> > > > >> > > > > > > > > protocol it
>> > > > >> > > > > > > > > > >> > would
>> > > > >> > > > > > > > > > >> > >> be nice clean-up.
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> Regards,
>> > > > >> > > > > > > > > > >> > >> --
>> > > > >> > > > > > > > > > >> > >> Ilya Kasnacheev
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> вт, 2 апр. 2019 г. в 09:55, Pavel
>> Tupitsyn <
>> > > > >> > > > > > > > ptupitsyn@apache.org
>> > > > >> > > > > > > > > >:
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> > >> > Alex,
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> > > now we can only support one active
>> > > > >> transaction
>> > > > >> > > per
>> > > > >> > > > > > > > connection
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> > I totally understand server-side and
>> > > protocol
>> > > > >> > > > limitations
>> > > > >> > > > > > > > that
>> > > > >> > > > > > > > > are
>> > > > >> > > > > > > > > > >> > >> causing
>> > > > >> > > > > > > > > > >> > >> > this.
>> > > > >> > > > > > > > > > >> > >> > But I have no idea how to support
>> this in
>> > > > >> .NET Thin
>> > > > >> > > > > > Client,
>> > > > >> > > > > > > > for
>> > > > >> > > > > > > > > > >> > example.
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> > It is thread-safe and can handle
>> multiple
>> > > > >> async
>> > > > >> > > > > > operations
>> > > > >> > > > > > > in
>> > > > >> > > > > > > > > > >> > parallel.
>> > > > >> > > > > > > > > > >> > >> > But with TX support we have to
>> somehow
>> > > switch
>> > > > >> to
>> > > > >> > > > > > > > > single-threaded
>> > > > >> > > > > > > > > > >> mode
>> > > > >> > > > > > > > > > >> > to
>> > > > >> > > > > > > > > > >> > >> > avoid unexpected effects.
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> > Any ideas?
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex
>> > > Plehanov <
>> > > > >> > > > > > > > > > >> plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > wrote:
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >> > > Dmitriy, thank you!
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > > Guys, I've created the IEP [1] on
>> wiki,
>> > > > >> please
>> > > > >> > > > have a
>> > > > >> > > > > > > look.
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > > [1]
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> >
>> > > > >> > > > > > > > > > >> > >>
>> > > > >> > > > > > > > > > >> >
>> > > > >> > > > > > > > > > >>
>> > > > >> > > > > > > > >
>> > > > >> > > > > > > >
>> > > > >> > > > > > >
>> > > > >> > > > > >
>> > > > >> > > >
>> > > > >> > >
>> > > > >>
>> > >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > > чт, 28 мар. 2019 г. в 14:33,
>> Dmitriy
>> > > Pavlov
>> > > > >> <
>> > > > >> > > > > > > > > dpavlov@apache.org
>> > > > >> > > > > > > > > > >> >:
>> > > > >> > > > > > > > > > >> > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > Hi,
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > I've added permissions to account
>> > > > >> plehanov.alex
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > Recently Infra integrated Apache
>> LDAP
>> > > with
>> > > > >> > > > > > confluence,
>> > > > >> > > > > > > so
>> > > > >> > > > > > > > > it is
>> > > > >> > > > > > > > > > >> > >> > possible
>> > > > >> > > > > > > > > > >> > >> > > to
>> > > > >> > > > > > > > > > >> > >> > > > login using Apache credentials.
>> > > Probably
>> > > > >> we can
>> > > > >> > > > ask
>> > > > >> > > > > > > infra
>> > > > >> > > > > > > > > if
>> > > > >> > > > > > > > > > >> extra
>> > > > >> > > > > > > > > > >> > >> > > > permissions to edit pages should
>> be
>> > > added
>> > > > >> for
>> > > > >> > > > > > > committers.
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > Sincerely,
>> > > > >> > > > > > > > > > >> > >> > > > Dmitriy Pavlov
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex
>> > > > >> Plehanov <
>> > > > >> > > > > > > > > > >> > plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >> >:
>> > > > >> > > > > > > > > > >> > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > Vladimir,
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > About current tx: ok, then we
>> don't
>> > > > >> need tx()
>> > > > >> > > > > > method
>> > > > >> > > > > > > in
>> > > > >> > > > > > > > > the
>> > > > >> > > > > > > > > > >> > >> interface
>> > > > >> > > > > > > > > > >> > >> > > at
>> > > > >> > > > > > > > > > >> > >> > > > > all (the same cached
>> transaction
>> > > info
>> > > > >> user
>> > > > >> > > can
>> > > > >> > > > > > store
>> > > > >> > > > > > > by
>> > > > >> > > > > > > > > > >> > himself).
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > About decoupling transactions
>> from
>> > > > >> threads on
>> > > > >> > > > the
>> > > > >> > > > > > > > server
>> > > > >> > > > > > > > > > >> side:
>> > > > >> > > > > > > > > > >> > for
>> > > > >> > > > > > > > > > >> > >> > now,
>> > > > >> > > > > > > > > > >> > >> > > > we
>> > > > >> > > > > > > > > > >> > >> > > > > can start with
>> thread-per-connection
>> > > > >> approach
>> > > > >> > > > (we
>> > > > >> > > > > > > only
>> > > > >> > > > > > > > > can
>> > > > >> > > > > > > > > > >> > support
>> > > > >> > > > > > > > > > >> > >> > one
>> > > > >> > > > > > > > > > >> > >> > > > > active transaction per
>> connection,
>> > > see
>> > > > >> below,
>> > > > >> > > > so we
>> > > > >> > > > > > > > need
>> > > > >> > > > > > > > > one
>> > > > >> > > > > > > > > > >> > >> > additional
>> > > > >> > > > > > > > > > >> > >> > > > > dedicated thread for each
>> connection
>> > > > >> with
>> > > > >> > > > active
>> > > > >> > > > > > > > > > >> transaction),
>> > > > >> > > > > > > > > > >> > and
>> > > > >> > > > > > > > > > >> > >> > > later
>> > > > >> > > > > > > > > > >> > >> > > > > change server-side internals to
>> > > process
>> > > > >> > > client
>> > > > >> > > > > > > > > transactions
>> > > > >> > > > > > > > > > >> in
>> > > > >> > > > > > > > > > >> > any
>> > > > >> > > > > > > > > > >> > >> > > server
>> > > > >> > > > > > > > > > >> > >> > > > > thread (not dedicated to this
>> > > > >> connection).
>> > > > >> > > This
>> > > > >> > > > > > > change
>> > > > >> > > > > > > > > will
>> > > > >> > > > > > > > > > >> not
>> > > > >> > > > > > > > > > >> > >> > affect
>> > > > >> > > > > > > > > > >> > >> > > > the
>> > > > >> > > > > > > > > > >> > >> > > > > thin client protocol, it only
>> > > affects
>> > > > >> the
>> > > > >> > > > server
>> > > > >> > > > > > > side.
>> > > > >> > > > > > > > > > >> > >> > > > > In any case, we can't support
>> > > concurrent
>> > > > >> > > > > > transactions
>> > > > >> > > > > > > > per
>> > > > >> > > > > > > > > > >> > >> connection
>> > > > >> > > > > > > > > > >> > >> > on
>> > > > >> > > > > > > > > > >> > >> > > > > the client side without
>> fundamental
>> > > > >> changes
>> > > > >> > > to
>> > > > >> > > > the
>> > > > >> > > > > > > > > current
>> > > > >> > > > > > > > > > >> > >> protocol
>> > > > >> > > > > > > > > > >> > >> > > > (cache
>> > > > >> > > > > > > > > > >> > >> > > > > operation doesn't bound to
>> > > transaction
>> > > > >> or
>> > > > >> > > > thread
>> > > > >> > > > > > and
>> > > > >> > > > > > > > the
>> > > > >> > > > > > > > > > >> server
>> > > > >> > > > > > > > > > >> > >> > doesn't
>> > > > >> > > > > > > > > > >> > >> > > > > know which thread on the client
>> > > side do
>> > > > >> this
>> > > > >> > > > cache
>> > > > >> > > > > > > > > > >> operation).
>> > > > >> > > > > > > > > > >> > In
>> > > > >> > > > > > > > > > >> > >> my
>> > > > >> > > > > > > > > > >> > >> > > > > opinion, if a user wants to use
>> > > > >> concurrent
>> > > > >> > > > > > > > transactions,
>> > > > >> > > > > > > > > he
>> > > > >> > > > > > > > > > >> must
>> > > > >> > > > > > > > > > >> > >> use
>> > > > >> > > > > > > > > > >> > >> > > > > different connections from a
>> > > connection
>> > > > >> pool.
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > About semantics of
>> suspend/resume
>> > > on the
>> > > > >> > > > > > client-side:
>> > > > >> > > > > > > > > it's
>> > > > >> > > > > > > > > > >> > >> absolutely
>> > > > >> > > > > > > > > > >> > >> > > > > different than server-side
>> > > semantics (we
>> > > > >> > > don't
>> > > > >> > > > need
>> > > > >> > > > > > > to
>> > > > >> > > > > > > > do
>> > > > >> > > > > > > > > > >> > >> > > suspend/resume
>> > > > >> > > > > > > > > > >> > >> > > > to
>> > > > >> > > > > > > > > > >> > >> > > > > pass transaction between
>> threads on
>> > > the
>> > > > >> > > > > > client-side),
>> > > > >> > > > > > > > but
>> > > > >> > > > > > > > > > >> can't
>> > > > >> > > > > > > > > > >> > be
>> > > > >> > > > > > > > > > >> > >> > > > > implemented efficiently without
>> > > > >> implemented
>> > > > >> > > > > > > > > suspend/resume on
>> > > > >> > > > > > > > > > >> > >> > > > server-side.
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > Can anyone give me permissions
>> to
>> > > > >> create IEP
>> > > > >> > > on
>> > > > >> > > > > > > Apache
>> > > > >> > > > > > > > > wiki?
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > ср, 27 мар. 2019 г. в 11:59,
>> > > Vladimir
>> > > > >> Ozerov
>> > > > >> > > <
>> > > > >> > > > > > > > > > >> > >> vozerov@gridgain.com>:
>> > > > >> > > > > > > > > > >> > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > Hi Alex,
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > My comments was only about
>> the
>> > > > >> protocol.
>> > > > >> > > > Getting
>> > > > >> > > > > > > > > current
>> > > > >> > > > > > > > > > >> info
>> > > > >> > > > > > > > > > >> > >> about
>> > > > >> > > > > > > > > > >> > >> > > > > > transaction should be
>> handled by
>> > > the
>> > > > >> client
>> > > > >> > > > > > itself.
>> > > > >> > > > > > > > It
>> > > > >> > > > > > > > > is
>> > > > >> > > > > > > > > > >> not
>> > > > >> > > > > > > > > > >> > >> > > protocl's
>> > > > >> > > > > > > > > > >> > >> > > > > > concern. Same about other
>> APIs and
>> > > > >> behavior
>> > > > >> > > > in
>> > > > >> > > > > > case
>> > > > >> > > > > > > > > another
>> > > > >> > > > > > > > > > >> > >> > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > is
>> > > > >> > > > > > > > > > >> > >> > > > > > attempted from the same
>> thread.
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > Putting protocol aside,
>> > > transaction
>> > > > >> support
>> > > > >> > > > is
>> > > > >> > > > > > > > > complicated
>> > > > >> > > > > > > > > > >> > >> matter.
>> > > > >> > > > > > > > > > >> > >> > I
>> > > > >> > > > > > > > > > >> > >> > > > > would
>> > > > >> > > > > > > > > > >> > >> > > > > > propose to route through IEP
>> and
>> > > wide
>> > > > >> > > > community
>> > > > >> > > > > > > > > > >> discussion. We
>> > > > >> > > > > > > > > > >> > >> need
>> > > > >> > > > > > > > > > >> > >> > > to
>> > > > >> > > > > > > > > > >> > >> > > > > > review API and semantics very
>> > > > >> carefully,
>> > > > >> > > > taking
>> > > > >> > > > > > > > > > >> SUSPEND/RESUME
>> > > > >> > > > > > > > > > >> > >> in
>> > > > >> > > > > > > > > > >> > >> > > > count.
>> > > > >> > > > > > > > > > >> > >> > > > > > Also I do not see how we
>> support
>> > > > >> client
>> > > > >> > > > > > > transactions
>> > > > >> > > > > > > > > > >> > efficiently
>> > > > >> > > > > > > > > > >> > >> > > > without
>> > > > >> > > > > > > > > > >> > >> > > > > > decoupling transactions from
>> > > threads
>> > > > >> on the
>> > > > >> > > > > > server
>> > > > >> > > > > > > > side
>> > > > >> > > > > > > > > > >> first.
>> > > > >> > > > > > > > > > >> > >> > > Because
>> > > > >> > > > > > > > > > >> > >> > > > > > without it you will need a
>> > > dedicated
>> > > > >> server
>> > > > >> > > > > > thread
>> > > > >> > > > > > > > for
>> > > > >> > > > > > > > > > >> every
>> > > > >> > > > > > > > > > >> > >> > client's
>> > > > >> > > > > > > > > > >> > >> > > > > > transaction which is slow
>> and may
>> > > even
>> > > > >> > > crash
>> > > > >> > > > the
>> > > > >> > > > > > > > > server.
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > Vladimir.
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > On Wed, Mar 27, 2019 at
>> 11:44 AM
>> > > Alex
>> > > > >> > > > Plehanov <
>> > > > >> > > > > > > > > > >> > >> > > > plehanov.alex@gmail.com>
>> > > > >> > > > > > > > > > >> > >> > > > > > wrote:
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > Vladimir, what if we want
>> to get
>> > > > >> current
>> > > > >> > > > > > > > transaction
>> > > > >> > > > > > > > > info
>> > > > >> > > > > > > > > > >> > >> (tx()
>> > > > >> > > > > > > > > > >> > >> > > > > method)?
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > Does close() method mapped
>> to
>> > > > >> > > > TX_END(rollback)?
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > For example, this code:
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > try(tx = txStart()) {
>> > > > >> > > > > > > > > > >> > >> > > > > > >     tx.commit();
>> > > > >> > > > > > > > > > >> > >> > > > > > > }
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > Will produce:
>> > > > >> > > > > > > > > > >> > >> > > > > > > TX_START
>> > > > >> > > > > > > > > > >> > >> > > > > > > TX_END(commit)
>> > > > >> > > > > > > > > > >> > >> > > > > > > TX_END(rollback)
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > Am I understand you right?
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > About xid. There is yet
>> another
>> > > > >> proposal.
>> > > > >> > > > Use
>> > > > >> > > > > > > some
>> > > > >> > > > > > > > > unique
>> > > > >> > > > > > > > > > >> > per
>> > > > >> > > > > > > > > > >> > >> > > > > connection
>> > > > >> > > > > > > > > > >> > >> > > > > > id
>> > > > >> > > > > > > > > > >> > >> > > > > > > (integer, simple counter)
>> for
>> > > > >> identifying
>> > > > >> > > > the
>> > > > >> > > > > > > > > > >> transaction on
>> > > > >> > > > > > > > > > >> > >> > > > > > > commit/rollback message.
>> The
>> > > client
>> > > > >> gets
>> > > > >> > > > this
>> > > > >> > > > > > id
>> > > > >> > > > > > > > > from the
>> > > > >> > > > > > > > > > >> > >> server
>> > > > >> > > > > > > > > > >> > >> > > with
>> > > > >> > > > > > > > > > >> > >> > > > > > > transaction info and sends
>> it
>> > > back
>> > > > >> to the
>> > > > >> > > > > > server
>> > > > >> > > > > > > > when
>> > > > >> > > > > > > > > > >> trying
>> > > > >> > > > > > > > > > >> > >> to
>> > > > >> > > > > > > > > > >> > >> > > > > > > commit/rollback
>> transaction.
>> > > This
>> > > > >> id is
>> > > > >> > > not
>> > > > >> > > > > > shown
>> > > > >> > > > > > > > to
>> > > > >> > > > > > > > > > >> users.
>> > > > >> > > > > > > > > > >> > >> But
>> > > > >> > > > > > > > > > >> > >> > > also
>> > > > >> > > > > > > > > > >> > >> > > > we
>> > > > >> > > > > > > > > > >> > >> > > > > > can
>> > > > >> > > > > > > > > > >> > >> > > > > > > pass from server to client
>> real
>> > > > >> > > > transaction id
>> > > > >> > > > > > > > (xid)
>> > > > >> > > > > > > > > with
>> > > > >> > > > > > > > > > >> > >> > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > info
>> > > > >> > > > > > > > > > >> > >> > > > > > > for diagnostic purposes.
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > And one more question: what
>> > > should
>> > > > >> we do
>> > > > >> > > > if the
>> > > > >> > > > > > > > > client
>> > > > >> > > > > > > > > > >> > starts
>> > > > >> > > > > > > > > > >> > >> a
>> > > > >> > > > > > > > > > >> > >> > new
>> > > > >> > > > > > > > > > >> > >> > > > > > > transaction without ending
>> the
>> > > old
>> > > > >> one?
>> > > > >> > > > Should
>> > > > >> > > > > > we
>> > > > >> > > > > > > > > end the
>> > > > >> > > > > > > > > > >> > old
>> > > > >> > > > > > > > > > >> > >> > > > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > implicitly (rollback) or
>> throw
>> > > an
>> > > > >> > > > exception to
>> > > > >> > > > > > > the
>> > > > >> > > > > > > > > > >> client?
>> > > > >> > > > > > > > > > >> > In
>> > > > >> > > > > > > > > > >> > >> my
>> > > > >> > > > > > > > > > >> > >> > > > > opinion,
>> > > > >> > > > > > > > > > >> > >> > > > > > > the first option is
>> better. For
>> > > > >> example,
>> > > > >> > > > if we
>> > > > >> > > > > > > got
>> > > > >> > > > > > > > a
>> > > > >> > > > > > > > > > >> > >> previously
>> > > > >> > > > > > > > > > >> > >> > > used
>> > > > >> > > > > > > > > > >> > >> > > > > > > connection from the
>> connection
>> > > > >> pool, we
>> > > > >> > > > should
>> > > > >> > > > > > > not
>> > > > >> > > > > > > > > worry
>> > > > >> > > > > > > > > > >> > about
>> > > > >> > > > > > > > > > >> > >> > any
>> > > > >> > > > > > > > > > >> > >> > > > > > > uncompleted transaction
>> started
>> > > by
>> > > > >> the
>> > > > >> > > > previous
>> > > > >> > > > > > > > user
>> > > > >> > > > > > > > > of
>> > > > >> > > > > > > > > > >> this
>> > > > >> > > > > > > > > > >> > >> > > > > connection.
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > ср, 27 мар. 2019 г. в
>> 11:02,
>> > > > >> Vladimir
>> > > > >> > > > Ozerov <
>> > > > >> > > > > > > > > > >> > >> > vozerov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > As far as
>> > > > >> SUSPEND/RESUME/SAVEPOINT - we
>> > > > >> > > > do
>> > > > >> > > > > > not
>> > > > >> > > > > > > > > support
>> > > > >> > > > > > > > > > >> > them
>> > > > >> > > > > > > > > > >> > >> > yet,
>> > > > >> > > > > > > > > > >> > >> > > > and
>> > > > >> > > > > > > > > > >> > >> > > > > > > adding
>> > > > >> > > > > > > > > > >> > >> > > > > > > > them in future should not
>> > > > >> conflict with
>> > > > >> > > > > > simple
>> > > > >> > > > > > > > > > >> START/END
>> > > > >> > > > > > > > > > >> > >> > > > > > infrastructure.
>> > > > >> > > > > > > > > > >> > >> > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > On Wed, Mar 27, 2019 at
>> 11:00
>> > > AM
>> > > > >> > > Vladimir
>> > > > >> > > > > > > Ozerov
>> > > > >> > > > > > > > <
>> > > > >> > > > > > > > > > >> > >> > > > > vozerov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > wrote:
>> > > > >> > > > > > > > > > >> > >> > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > Hi Alex,
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > I am not sure we need 5
>> > > > >> commands.
>> > > > >> > > > Wouldn't
>> > > > >> > > > > > it
>> > > > >> > > > > > > > be
>> > > > >> > > > > > > > > > >> enough
>> > > > >> > > > > > > > > > >> > to
>> > > > >> > > > > > > > > > >> > >> > have
>> > > > >> > > > > > > > > > >> > >> > > > > only
>> > > > >> > > > > > > > > > >> > >> > > > > > > two?
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > START - accepts
>> optional
>> > > > >> parameters,
>> > > > >> > > > > > returns
>> > > > >> > > > > > > > > > >> transaction
>> > > > >> > > > > > > > > > >> > >> info
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > END - provides commit
>> flag,
>> > > > >> returns
>> > > > >> > > > void
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > Vladimir.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > On Wed, Mar 27, 2019 at
>> > > 8:26 AM
>> > > > >> Alex
>> > > > >> > > > > > > Plehanov <
>> > > > >> > > > > > > > > > >> > >> > > > > > plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >> > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > > wrote:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> Sergey, yes, the
>> close is
>> > > > >> something
>> > > > >> > > > like
>> > > > >> > > > > > > > silent
>> > > > >> > > > > > > > > > >> > rollback.
>> > > > >> > > > > > > > > > >> > >> > But
>> > > > >> > > > > > > > > > >> > >> > > we
>> > > > >> > > > > > > > > > >> > >> > > > > can
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> also implement this
>> on the
>> > > > >> client
>> > > > >> > > > side,
>> > > > >> > > > > > just
>> > > > >> > > > > > > > > using
>> > > > >> > > > > > > > > > >> > >> rollback
>> > > > >> > > > > > > > > > >> > >> > > and
>> > > > >> > > > > > > > > > >> > >> > > > > > > ignoring
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> errors in the
>> response.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> ср, 27 мар. 2019 г. в
>> > > 00:04,
>> > > > >> Sergey
>> > > > >> > > > > > Kozlov <
>> > > > >> > > > > > > > > > >> > >> > > > skozlov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >>
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > Nikolay
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > Am I correctly
>> > > understand you
>> > > > >> > > > points:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >    - close: rollback
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >    - commit, close:
>> do
>> > > > >> nothing
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >    - rollback,
>> close: do
>> > > > >> what? (I
>> > > > >> > > > > > suppose
>> > > > >> > > > > > > > > nothing)
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > Also you assume that
>> > > after
>> > > > >> > > > > > commit/rollback
>> > > > >> > > > > > > > we
>> > > > >> > > > > > > > > may
>> > > > >> > > > > > > > > > >> > need
>> > > > >> > > > > > > > > > >> > >> to
>> > > > >> > > > > > > > > > >> > >> > > free
>> > > > >> > > > > > > > > > >> > >> > > > > > some
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > resources on server
>> > > > >> node(s)or just
>> > > > >> > > > do on
>> > > > >> > > > > > > > > client
>> > > > >> > > > > > > > > > >> > started
>> > > > >> > > > > > > > > > >> > >> > TX?
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > On Tue, Mar 26,
>> 2019 at
>> > > > >> 10:41 PM
>> > > > >> > > > Alex
>> > > > >> > > > > > > > > Plehanov <
>> > > > >> > > > > > > > > > >> > >> > > > > > > > plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > wrote:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > Sergey, we have
>> the
>> > > close()
>> > > > >> > > > method in
>> > > > >> > > > > > > the
>> > > > >> > > > > > > > > thick
>> > > > >> > > > > > > > > > >> > >> client,
>> > > > >> > > > > > > > > > >> > >> > > it's
>> > > > >> > > > > > > > > > >> > >> > > > > > > > behavior
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> is
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > slightly
>> different than
>> > > > >> > > rollback()
>> > > > >> > > > > > > method
>> > > > >> > > > > > > > > (it
>> > > > >> > > > > > > > > > >> > should
>> > > > >> > > > > > > > > > >> > >> > > > rollback
>> > > > >> > > > > > > > > > >> > >> > > > > if
>> > > > >> > > > > > > > > > >> > >> > > > > > > the
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > transaction is not
>> > > > >> committed and
>> > > > >> > > > do
>> > > > >> > > > > > > > nothing
>> > > > >> > > > > > > > > if
>> > > > >> > > > > > > > > > >> the
>> > > > >> > > > > > > > > > >> > >> > > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > is
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> already
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > committed). I
>> think we
>> > > > >> should
>> > > > >> > > > support
>> > > > >> > > > > > > > > > >> > >> try-with-resource
>> > > > >> > > > > > > > > > >> > >> > > > > > semantics
>> > > > >> > > > > > > > > > >> > >> > > > > > > in
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> the
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > thin client and
>> > > > >> OP_TX_CLOSE will
>> > > > >> > > > be
>> > > > >> > > > > > > useful
>> > > > >> > > > > > > > > here.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > Nikolay,
>> suspend/resume
>> > > > >> didn't
>> > > > >> > > > work
>> > > > >> > > > > > yet
>> > > > >> > > > > > > > for
>> > > > >> > > > > > > > > > >> > >> pessimistic
>> > > > >> > > > > > > > > > >> > >> > > > > > > > transactions.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > Also,
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > the main goal of
>> > > > >> suspend/resume
>> > > > >> > > > > > > operations
>> > > > >> > > > > > > > > is to
>> > > > >> > > > > > > > > > >> > >> support
>> > > > >> > > > > > > > > > >> > >> > > > > > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > passing between
>> > > threads.
>> > > > >> In the
>> > > > >> > > > thin
>> > > > >> > > > > > > > > client, the
>> > > > >> > > > > > > > > > >> > >> > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > is
>> > > > >> > > > > > > > > > >> > >> > > > > > > > bound
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> to
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > the client
>> connection,
>> > > not
>> > > > >> > > client
>> > > > >> > > > > > > thread.
>> > > > >> > > > > > > > I
>> > > > >> > > > > > > > > > >> think
>> > > > >> > > > > > > > > > >> > >> > passing
>> > > > >> > > > > > > > > > >> > >> > > a
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > between different
>> > > client
>> > > > >> > > > connections
>> > > > >> > > > > > is
>> > > > >> > > > > > > > not
>> > > > >> > > > > > > > > a
>> > > > >> > > > > > > > > > >> very
>> > > > >> > > > > > > > > > >> > >> > useful
>> > > > >> > > > > > > > > > >> > >> > > > > case.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > вт, 26 мар. 2019
>> г. в
>> > > > >> 22:17,
>> > > > >> > > > Nikolay
>> > > > >> > > > > > > > > Izhikov <
>> > > > >> > > > > > > > > > >> > >> > > > > > nizhikov@apache.org
>> > > > >> > > > > > > > > > >> > >> > > > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Hello, Alex.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > We also have
>> suspend
>> > > and
>> > > > >> > > resume
>> > > > >> > > > > > > > > operations.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > I think we
>> should
>> > > > >> support them
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > вт, 26 марта
>> 2019 г.,
>> > > > >> 22:07
>> > > > >> > > > Sergey
>> > > > >> > > > > > > > Kozlov
>> > > > >> > > > > > > > > <
>> > > > >> > > > > > > > > > >> > >> > > > > > skozlov@gridgain.com
>> > > > >> > > > > > > > > > >> > >> > > > > > > >:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > Hi
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > Looks like I
>> missed
>> > > > >> > > something
>> > > > >> > > > but
>> > > > >> > > > > > > why
>> > > > >> > > > > > > > we
>> > > > >> > > > > > > > > > >> need
>> > > > >> > > > > > > > > > >> > >> > > > OP_TX_CLOSE
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> operation?
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > Also I
>> suggest to
>> > > > >> reserve a
>> > > > >> > > > code
>> > > > >> > > > > > for
>> > > > >> > > > > > > > > > >> SAVEPOINT
>> > > > >> > > > > > > > > > >> > >> > > operation
>> > > > >> > > > > > > > > > >> > >> > > > > > which
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> very
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > useful
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > to understand
>> where
>> > > > >> > > > transaction
>> > > > >> > > > > > has
>> > > > >> > > > > > > > been
>> > > > >> > > > > > > > > > >> rolled
>> > > > >> > > > > > > > > > >> > >> back
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > On Tue, Mar
>> 26,
>> > > 2019
>> > > > >> at 6:07
>> > > > >> > > > PM
>> > > > >> > > > > > Alex
>> > > > >> > > > > > > > > > >> Plehanov <
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> >
>> plehanov.alex@gmail.com
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > wrote:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > Hello
>> Igniters!
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > I want to
>> pick
>> > > up the
>> > > > >> > > ticket
>> > > > >> > > > > > > > > IGNITE-7369
>> > > > >> > > > > > > > > > >> and
>> > > > >> > > > > > > > > > >> > >> add
>> > > > >> > > > > > > > > > >> > >> > > > > > > transactions
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > support
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > to
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > our thin
>> client
>> > > > >> > > > implementation.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > I've looked
>> at
>> > > our
>> > > > >> current
>> > > > >> > > > > > > > > implementation
>> > > > >> > > > > > > > > > >> and
>> > > > >> > > > > > > > > > >> > >> have
>> > > > >> > > > > > > > > > >> > >> > > > some
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> proposals
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > to
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > support
>> > > transactions:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > Add new
>> > > operations
>> > > > >> to thin
>> > > > >> > > > > > client
>> > > > >> > > > > > > > > > >> protocol:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>>  OP_TX_GET,
>> > > 4000,
>> > > > >> Get
>> > > > >> > > > current
>> > > > >> > > > > > > > > > >> transaction
>> > > > >> > > > > > > > > > >> > >> for
>> > > > >> > > > > > > > > > >> > >> > > > client
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> connection
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>>  OP_TX_START,
>> > > > >> 4001,
>> > > > >> > > > Start a
>> > > > >> > > > > > new
>> > > > >> > > > > > > > > > >> > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>>  OP_TX_COMMIT,
>> > > > >> 4002,
>> > > > >> > > > Commit
>> > > > >> > > > > > > > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > >  OP_TX_ROLLBACK,
>> > > > >> 4003,
>> > > > >> > > > > > Rollback
>> > > > >> > > > > > > > > > >> > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>>  OP_TX_CLOSE,
>> > > > >> 4004,
>> > > > >> > > Close
>> > > > >> > > > > > > > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > From the
>> client
>> > > side
>> > > > >> > > (java)
>> > > > >> > > > new
>> > > > >> > > > > > > > > interfaces
>> > > > >> > > > > > > > > > >> > >> will be
>> > > > >> > > > > > > > > > >> > >> > > > > added:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > public
>> interface
>> > > > >> > > > > > > ClientTransactions
>> > > > >> > > > > > > > {
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > ClientTransaction
>> > > > >> > > > > > > > > txStart();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > ClientTransaction
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> txStart(TransactionConcurrency
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > concurrency,
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > TransactionIsolation
>> > > > >> > > > isolation);
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > ClientTransaction
>> > > > >> > > > > > > > > > >> > >> > > > > >
>> txStart(TransactionConcurrency
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > concurrency,
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > TransactionIsolation
>> > > > >> > > > isolation,
>> > > > >> > > > > > > long
>> > > > >> > > > > > > > > > >> timeout,
>> > > > >> > > > > > > > > > >> > >> int
>> > > > >> > > > > > > > > > >> > >> > > > > txSize);
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > ClientTransaction
>> > > > >> > > > > > tx();
>> > > > >> > > > > > > > //
>> > > > >> > > > > > > > > Get
>> > > > >> > > > > > > > > > >> > >> current
>> > > > >> > > > > > > > > > >> > >> > > > > > connection
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > transaction
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > > ClientTransactions
>> > > > >> > > > > > > > > > >> > withLabel(String
>> > > > >> > > > > > > > > > >> > >> > lb);
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > }
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > public
>> interface
>> > > > >> > > > > > ClientTransaction
>> > > > >> > > > > > > > > extends
>> > > > >> > > > > > > > > > >> > >> > > > > AutoCloseable {
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > IgniteUuid
>> > > > >> > > > xid(); //
>> > > > >> > > > > > Do
>> > > > >> > > > > > > > we
>> > > > >> > > > > > > > > need
>> > > > >> > > > > > > > > > >> > it?
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > > TransactionIsolation
>> > > > >> > > > > > > > > > >> isolation();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> > > > >> > > > > > TransactionConcurrency
>> > > > >> > > > > > > > > > >> > >> concurrency();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> long
>> > > > >> timeout();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> String
>> > > > >> label();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> void
>> > > > >> commit();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> void
>> > > > >> > > rollback();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >     public
>> void
>> > > > >> close();
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > }
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > From the
>> server
>> > > > >> side, I
>> > > > >> > > > think
>> > > > >> > > > > > as a
>> > > > >> > > > > > > > > first
>> > > > >> > > > > > > > > > >> step
>> > > > >> > > > > > > > > > >> > >> > (while
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> transactions
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> suspend/resume
>> > > is not
>> > > > >> > > fully
>> > > > >> > > > > > > > > implemented)
>> > > > >> > > > > > > > > > >> we
>> > > > >> > > > > > > > > > >> > can
>> > > > >> > > > > > > > > > >> > >> > use
>> > > > >> > > > > > > > > > >> > >> > > > the
>> > > > >> > > > > > > > > > >> > >> > > > > > same
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > approach
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > as
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > for JDBC:
>> add a
>> > > new
>> > > > >> worker
>> > > > >> > > > to
>> > > > >> > > > > > each
>> > > > >> > > > > > > > > > >> > >> > > > ClientRequestHandler
>> > > > >> > > > > > > > > > >> > >> > > > > > and
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> process
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > requests by
>> this
>> > > > >> worker if
>> > > > >> > > > the
>> > > > >> > > > > > > > > > >> transaction is
>> > > > >> > > > > > > > > > >> > >> > > started
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> explicitly.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > ClientRequestHandler
>> > > > >> is
>> > > > >> > > > bound to
>> > > > >> > > > > > > > > client
>> > > > >> > > > > > > > > > >> > >> > connection,
>> > > > >> > > > > > > > > > >> > >> > > so
>> > > > >> > > > > > > > > > >> > >> > > > > > there
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> will
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > be
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > 1:1
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > relation
>> between
>> > > > >> client
>> > > > >> > > > > > connection
>> > > > >> > > > > > > > and
>> > > > >> > > > > > > > > > >> > thread,
>> > > > >> > > > > > > > > > >> > >> > which
>> > > > >> > > > > > > > > > >> > >> > > > > > process
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > operations
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > in
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > a
>> transaction.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > Also, there
>> is a
>> > > > >> couple of
>> > > > >> > > > > > issues
>> > > > >> > > > > > > I
>> > > > >> > > > > > > > > want
>> > > > >> > > > > > > > > > >> to
>> > > > >> > > > > > > > > > >> > >> > discuss:
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > >
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > We have
>> > > overloaded
>> > > > >> method
>> > > > >> > > > > > txStart
>> > > > >> > > > > > > > > with a
>> > > > >> > > > > > > > > > >> > >> different
>> > > > >> > > > > > > > > > >> > >> > > set
>> > > > >> > > > > > > > > > >> > >> > > > > of
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > arguments.
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > Some
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> > > > > > of the
>> arguments
>> > > may
>> > > > >> be
>> > > > >> > > > missing.
>> > > > >> > > > > > > To
>> > > > >> > > > > > > > > pass
>> > > > >> > > > > > > > > > >> > >> arguments
>> > > > >> > > > > > > > > > >> > >> > > > with
>> > > > >> > > > > > > > > > >> > >> > > > > > > > >> OP_TX_START
>> > > > >> > > > > > > > > > >> > >> &
>> > > > >
>> > > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > > Ivan Pavlukhin
>> > >
>>
>>
>>
>> --
>> Best regards,
>> Ivan Pavlukhin
>>
>

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