ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Павлухин Иван <vololo...@gmail.com>
Subject Re: Thin client: transactions support
Date Mon, 27 May 2019 08:51:10 GMT
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

Mime
View raw message