Thin client: transactions support

[Alexey Plekhanov]

Ilya,

> We should be able to multiplex several transactions using a single Client
connection.
In this case, we should significantly change cache operations syntax (for
each implemented client), to bind each operation to the transaction.

> I want to also ask if "Number of entries participating in transaction
(may be approximate). 0 - default value." is needed.
I've tried to minimize API changes between thick and thin client to
simplify move from one to another. It's the only reason. But I agree with
you, the parameter is not very useful.


вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <[hidden email]>:

> Hello!
>
> Pavel, I agree with you thorougly. We should be able to multiplex several
> transactions using a single Client connection. This means adding
> Transaction id parameter to every affected cache operation / SQL statement
> (if applicable) to make sure we do cache operations on relevant
> transaction.
>
> This is how other things work in Ignite, such as communication. We do not
> open dozens of connections, we multiplex operations asynchronously through
> a single connection.
>
> I think that trying to pool Ignite connections will be highly inconvenient,
> since there is no existing infrastructure for such pooling (like there
> exists for JDBC).
>
> I want to also ask if "Number of entries participating in transaction (may
> be approximate). 0 - default value." is needed. Does it actually do
> anything in our tx protocol? Users of existing APIs are already confused by
> this parameter, if we could get rid of it in thin client protocol it would
> be nice clean-up.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]>:
>
> > Alex,
> >
> > > now we can only support one active transaction per connection
> >
> > I totally understand server-side and protocol limitations that are
> causing
> > this.
> > But I have no idea how to support this in .NET Thin Client, for example.
> >
> > It is thread-safe and can handle multiple async operations in parallel.
> > But with TX support we have to somehow switch to single-threaded mode to
> > avoid unexpected effects.
> >
> > Any ideas?
> >
> >
> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <[hidden email]>
> > wrote:
> >
> > > Dmitriy, thank you!
> > >
> > > Guys, I've created the IEP [1] on wiki, please have a look.
> > >
> > > [1]
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >
> > >
> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <[hidden email]>:
> > >
> > > > Hi,
> > > >
> > > > I've added permissions to account plehanov.alex
> > > >
> > > > Recently Infra integrated Apache LDAP with confluence, so it is
> > possible
> > > to
> > > > login using Apache credentials. Probably we can ask infra if extra
> > > > permissions to edit pages should be added for committers.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <[hidden email]
> >:
> > > >
> > > > > Vladimir,
> > > > >
> > > > > About current tx: ok, then we don't need tx() method in the
> interface
> > > at
> > > > > all (the same cached transaction info user can store by himself).
> > > > >
> > > > > About decoupling transactions from threads on the server side: for
> > now,
> > > > we
> > > > > can start with thread-per-connection approach (we only can support
> > one
> > > > > active transaction per connection, see below, so we need one
> > additional
> > > > > dedicated thread for each connection with active transaction), and
> > > later
> > > > > change server-side internals to process client transactions in any
> > > server
> > > > > thread (not dedicated to this connection). This change will not
> > affect
> > > > the
> > > > > thin client protocol, it only affects the server side.
> > > > > In any case, we can't support concurrent transactions per
> connection
> > on
> > > > > the client side without fundamental changes to the current protocol
> > > > (cache
> > > > > operation doesn't bound to transaction or thread and the server
> > doesn't
> > > > > know which thread on the client side do this cache operation). In
> my
> > > > > opinion, if a user wants to use concurrent transactions, he must
> use
> > > > > different connections from a connection pool.
> > > > >
> > > > > About semantics of suspend/resume on the client-side: it's
> absolutely
> > > > > different than server-side semantics (we don't need to do
> > > suspend/resume
> > > > to
> > > > > pass transaction between threads on the client-side), but can't be
> > > > > implemented efficiently without implemented suspend/resume on
> > > > server-side.
> > > > >
> > > > > Can anyone give me permissions to create IEP on Apache wiki?
> > > > >
> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <[hidden email]
> >:
> > > > >
> > > > > > Hi Alex,
> > > > > >
> > > > > > My comments was only about the protocol. Getting current info
> about
> > > > > > transaction should be handled by the client itself. It is not
> > > protocl's
> > > > > > concern. Same about other APIs and behavior in case another
> > > transaction
> > > > > is
> > > > > > attempted from the same thread.
> > > > > >
> > > > > > Putting protocol aside, transaction support is complicated
> matter.
> > I
> > > > > would
> > > > > > propose to route through IEP and wide community discussion. We
> need
> > > to
> > > > > > review API and semantics very carefully, taking SUSPEND/RESUME in
> > > > count.
> > > > > > Also I do not see how we support client transactions efficiently
> > > > without
> > > > > > decoupling transactions from threads on the server side first.
> > > Because
> > > > > > without it you will need a dedicated server thread for every
> > client's
> > > > > > transaction which is slow and may even crash the server.
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > >
> > > > > > > Vladimir, what if we want to get current transaction info (tx()
> > > > > method)?
> > > > > > >
> > > > > > > Does close() method mapped to TX_END(rollback)?
> > > > > > >
> > > > > > > For example, this code:
> > > > > > >
> > > > > > > try(tx = txStart()) {
> > > > > > >     tx.commit();
> > > > > > > }
> > > > > > >
> > > > > > > Will produce:
> > > > > > > TX_START
> > > > > > > TX_END(commit)
> > > > > > > TX_END(rollback)
> > > > > > >
> > > > > > > Am I understand you right?
> > > > > > >
> > > > > > > About xid. There is yet another proposal. Use some unique per
> > > > > connection
> > > > > > id
> > > > > > > (integer, simple counter) for identifying the transaction on
> > > > > > > commit/rollback message. The client gets this id from the
> server
> > > with
> > > > > > > transaction info and sends it back to the server when trying to
> > > > > > > commit/rollback transaction. This id is not shown to users. But
> > > also
> > > > we
> > > > > > can
> > > > > > > pass from server to client real transaction id (xid) with
> > > transaction
> > > > > > info
> > > > > > > for diagnostic purposes.
> > > > > > >
> > > > > > > And one more question: what should we do if the client starts a
> > new
> > > > > > > transaction without ending the old one? Should we end the old
> > > > > transaction
> > > > > > > implicitly (rollback) or throw an exception to the client? In
> my
> > > > > opinion,
> > > > > > > the first option is better. For example, if we got a previously
> > > used
> > > > > > > connection from the connection pool, we should not worry about
> > any
> > > > > > > uncompleted transaction started by the previous user of this
> > > > > connection.
> > > > > > >
> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> > [hidden email]
> > > >:
> > > > > > >
> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them
> > yet,
> > > > and
> > > > > > > adding
> > > > > > > > them in future should not conflict with simple START/END
> > > > > > infrastructure.
> > > > > > > >
> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> > > > > [hidden email]
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Alex,
> > > > > > > > >
> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be enough to
> > have
> > > > > only
> > > > > > > two?
> > > > > > > > >
> > > > > > > > > START - accepts optional parameters, returns transaction
> info
> > > > > > > > > END - provides commit flag, returns void
> > > > > > > > >
> > > > > > > > > Vladimir.
> > > > > > > > >
> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> > > > > > [hidden email]
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> Sergey, yes, the close is something like silent rollback.
> > But
> > > we
> > > > > can
> > > > > > > > >> also implement this on the client side, just using
> rollback
> > > and
> > > > > > > ignoring
> > > > > > > > >> errors in the response.
> > > > > > > > >>
> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> > > > [hidden email]
> > > > > >:
> > > > > > > > >>
> > > > > > > > >> > Nikolay
> > > > > > > > >> >
> > > > > > > > >> > Am I correctly understand you points:
> > > > > > > > >> >
> > > > > > > > >> >    - close: rollback
> > > > > > > > >> >    - commit, close: do nothing
> > > > > > > > >> >    - rollback, close: do what? (I suppose nothing)
> > > > > > > > >> >
> > > > > > > > >> > Also you assume that after commit/rollback we may need
> to
> > > free
> > > > > > some
> > > > > > > > >> > resources on server node(s)or just do on client started
> > TX?
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
> > > > > > > > [hidden email]
> > > > > > > > >> >
> > > > > > > > >> > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > Sergey, we have the close() method in the thick
> client,
> > > it's
> > > > > > > > behavior
> > > > > > > > >> is
> > > > > > > > >> > > slightly different than rollback() method (it should
> > > > rollback
> > > > > if
> > > > > > > the
> > > > > > > > >> > > transaction is not committed and do nothing if the
> > > > transaction
> > > > > > is
> > > > > > > > >> already
> > > > > > > > >> > > committed). I think we should support
> try-with-resource
> > > > > > semantics
> > > > > > > in
> > > > > > > > >> the
> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here.
> > > > > > > > >> > >
> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
> pessimistic
> > > > > > > > transactions.
> > > > > > > > >> > Also,
> > > > > > > > >> > > the main goal of suspend/resume operations is to
> support
> > > > > > > transaction
> > > > > > > > >> > > passing between threads. In the thin client, the
> > > transaction
> > > > > is
> > > > > > > > bound
> > > > > > > > >> to
> > > > > > > > >> > > the client connection, not client thread. I think
> > passing
> > > a
> > > > > > > > >> transaction
> > > > > > > > >> > > between different client connections is not a very
> > useful
> > > > > case.
> > > > > > > > >> > >
> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > > > >> > >
> > > > > > > > >> > > > Hello, Alex.
> > > > > > > > >> > > >
> > > > > > > > >> > > > We also have suspend and resume operations.
> > > > > > > > >> > > > I think we should support them
> > > > > > > > >> > > >
> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > > > > > [hidden email]
> > > > > > > >:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > Hi
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Looks like I missed something but why we need
> > > > OP_TX_CLOSE
> > > > > > > > >> operation?
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > Also I suggest to reserve a code for SAVEPOINT
> > > operation
> > > > > > which
> > > > > > > > >> very
> > > > > > > > >> > > > useful
> > > > > > > > >> > > > > to understand where transaction has been rolled
> back
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
> > > > > > > > >> > [hidden email]
> > > > > > > > >> > > >
> > > > > > > > >> > > > > wrote:
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > > Hello Igniters!
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369 and add
> > > > > > > transactions
> > > > > > > > >> > support
> > > > > > > > >> > > > to
> > > > > > > > >> > > > > > our thin client implementation.
> > > > > > > > >> > > > > > I've looked at our current implementation and
> have
> > > > some
> > > > > > > > >> proposals
> > > > > > > > >> > to
> > > > > > > > >> > > > > > support transactions:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Add new operations to thin client protocol:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current transaction for
> > > > client
> > > > > > > > >> connection
> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new transaction
> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit transaction
> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback transaction
> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close transaction
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > From the client side (java) new interfaces will
> be
> > > > > added:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > public interface ClientTransactions {
> > > > > > > > >> > > > > >     public ClientTransaction txStart();
> > > > > > > > >> > > > > >     public ClientTransaction
> > > > > > txStart(TransactionConcurrency
> > > > > > > > >> > > > concurrency,
> > > > > > > > >> > > > > > TransactionIsolation isolation);
> > > > > > > > >> > > > > >     public ClientTransaction
> > > > > > txStart(TransactionConcurrency
> > > > > > > > >> > > > concurrency,
> > > > > > > > >> > > > > > TransactionIsolation isolation, long timeout,
> int
> > > > > txSize);
> > > > > > > > >> > > > > >     public ClientTransaction tx(); // Get
> current
> > > > > > connection
> > > > > > > > >> > > > transaction
> > > > > > > > >> > > > > >     public ClientTransactions withLabel(String
> > lb);
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > public interface ClientTransaction extends
> > > > > AutoCloseable {
> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we need it?
> > > > > > > > >> > > > > >     public TransactionIsolation isolation();
> > > > > > > > >> > > > > >     public TransactionConcurrency concurrency();
> > > > > > > > >> > > > > >     public long timeout();
> > > > > > > > >> > > > > >     public String label();
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > >     public void commit();
> > > > > > > > >> > > > > >     public void rollback();
> > > > > > > > >> > > > > >     public void close();
> > > > > > > > >> > > > > > }
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > From the server side, I think as a first step
> > (while
> > > > > > > > >> transactions
> > > > > > > > >> > > > > > suspend/resume is not fully implemented) we can
> > use
> > > > the
> > > > > > same
> > > > > > > > >> > approach
> > > > > > > > >> > > > as
> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> > > > ClientRequestHandler
> > > > > > and
> > > > > > > > >> process
> > > > > > > > >> > > > > > requests by this worker if the transaction is
> > > started
> > > > > > > > >> explicitly.
> > > > > > > > >> > > > > > ClientRequestHandler is bound to client
> > connection,
> > > so
> > > > > > there
> > > > > > > > >> will
> > > > > > > > >> > be
> > > > > > > > >> > > > 1:1
> > > > > > > > >> > > > > > relation between client connection and thread,
> > which
> > > > > > process
> > > > > > > > >> > > operations
> > > > > > > > >> > > > > in
> > > > > > > > >> > > > > > a transaction.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Also, there is a couple of issues I want to
> > discuss:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > We have overloaded method txStart with a
> different
> > > set
> > > > > of
> > > > > > > > >> > arguments.
> > > > > > > > >> > > > Some
> > > > > > > > >> > > > > > of the arguments may be missing. To pass
> arguments
> > > > with
> > > > > > > > >> OP_TX_START
> > > > > > > > >> > > > > > operation we have the next options:
> > > > > > > > >> > > > > >  * Serialize full set of arguments and use some
> > > value
> > > > > for
> > > > > > > > >> missing
> > > > > > > > >> > > > > > arguments. For example -1 for int/long types and
> > > null
> > > > > for
> > > > > > > > string
> > > > > > > > >> > > type.
> > > > > > > > >> > > > We
> > > > > > > > >> > > > > > can't use 0 for int/long types since 0 it's a
> > valid
> > > > > value
> > > > > > > for
> > > > > > > > >> > > > > concurrency,
> > > > > > > > >> > > > > > isolation and timeout arguments.
> > > > > > > > >> > > > > >  * Serialize arguments as a collection of
> > > > property-value
> > > > > > > pairs
> > > > > > > > >> > (like
> > > > > > > > >> > > > it's
> > > > > > > > >> > > > > > implemented now for CacheConfiguration). In this
> > > case
> > > > > only
> > > > > > > > >> > explicitly
> > > > > > > > >> > > > > > provided arguments will be serialized.
> > > > > > > > >> > > > > > Which way is better? The simplest solution is to
> > use
> > > > the
> > > > > > > first
> > > > > > > > >> > option
> > > > > > > > >> > > > > and I
> > > > > > > > >> > > > > > want to use it if there were no objections.
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > Do we need transaction id (xid) on the client
> > side?
> > > > > > > > >> > > > > > If yes, we can pass xid along with OP_TX_COMMIT,
> > > > > > > > OP_TX_ROLLBACK,
> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server and do
> > > > > > additional
> > > > > > > > >> check
> > > > > > > > >> > on
> > > > > > > > >> > > > the
> > > > > > > > >> > > > > > server side (current transaction id for
> connection
> > > ==
> > > > > > > > >> transaction
> > > > > > > > >> > id
> > > > > > > > >> > > > > passed
> > > > > > > > >> > > > > > from client side). This, perhaps, will protect
> > > clients
> > > > > > > against
> > > > > > > > >> some
> > > > > > > > >> > > > > errors
> > > > > > > > >> > > > > > (for example when client try to commit outdated
> > > > > > > transaction).
> > > > > > > > >> But
> > > > > > > > >> > > > > > currently, we don't have data type IgniteUuid in
> > > thin
> > > > > > client
> > > > > > > > >> > > protocol.
> > > > > > > > >> > > > Do
> > > > > > > > >> > > > > > we need to add it too?
> > > > > > > > >> > > > > > Also, we can pass xid as a string just to inform
> > the
> > > > > > client
> > > > > > > > and
> > > > > > > > >> do
> > > > > > > > >> > > not
> > > > > > > > >> > > > > pass
> > > > > > > > >> > > > > > it back to the server with commit/rollback
> > > operation.
> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick client
> works
> > > > this
> > > > > > way
> > > > > > > as
> > > > > > > > >> far
> > > > > > > > >> > > as I
> > > > > > > > >> > > > > > know).
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > What do you think?
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir Ozerov <
> > > > > > > > >> [hidden email]
> > > > > > > > >> > >:
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > > We already have transactions support in JDBC
> > > driver
> > > > in
> > > > > > TX
> > > > > > > > SQL
> > > > > > > > >> > > branch
> > > > > > > > >> > > > > > > (ignite-4191). Currently it is implemented
> > through
> > > > > > > separate
> > > > > > > > >> > thread,
> > > > > > > > >> > > > > which
> > > > > > > > >> > > > > > > is not that efficient. Ideally we need to
> finish
> > > > > > > decoupling
> > > > > > > > >> > > > > transactions
> > > > > > > > >> > > > > > > from threads. But alternatively we can change
> > the
> > > > > logic
> > > > > > on
> > > > > > > > >> how we
> > > > > > > > >> > > > > assign
> > > > > > > > >> > > > > > > thread ID to specific transaction and
> > > "impersonate"
> > > > > thin
> > > > > > > > >> client
> > > > > > > > >> > > > worker
> > > > > > > > >> > > > > > > threads when serving requests from multiple
> > users.
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda <
> > > > > > > > >> [hidden email]>
> > > > > > > > >> > > > > wrote:
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > > Here is an original discussion with a
> > reference
> > > to
> > > > > the
> > > > > > > > JIRA
> > > > > > > > >> > > ticket:
> > > > > > > > >> > > > > > > >
> > > http://apache-ignite-developers.2346864.n4.nabble
> > > > .
> > > > > > > > >> > > > > > > >
> > > > > > > > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > > > > > > > >> > > > > > > > Protocol-td25914.html
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > --
> > > > > > > > >> > > > > > > > Denis
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy
> > > Setrakyan
> > > > <
> > > > > > > > >> > > > > > [hidden email]
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > wrote:
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a design
> > > > > proposal
> > > > > > > for
> > > > > > > > >> > > > transaction
> > > > > > > > >> > > > > > > > support
> > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking this
> > > > > initiative
> > > > > > > and
> > > > > > > > >> > > creating
> > > > > > > > >> > > > an
> > > > > > > > >> > > > > > IEP
> > > > > > > > >> > > > > > > > on
> > > > > > > > >> > > > > > > > > Wiki?
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > D.
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy
> > > > > Govorukhin <
> > > > > > > > >> > > > > > > > > [hidden email]> wrote:
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions about
> thin
> > > > client
> > > > > > and
> > > > > > > > >> binary
> > > > > > > > >> > > > > > protocol,
> > > > > > > > >> > > > > > > > > but I
> > > > > > > > >> > > > > > > > > > did not hear anything about transactions
> > > > > support.
> > > > > > Do
> > > > > > > > we
> > > > > > > > >> > have
> > > > > > > > >> > > > some
> > > > > > > > >> > > > > > > draft
> > > > > > > > >> > > > > > > > > for
> > > > > > > > >> > > > > > > > > > this purpose?
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > As I understand we have several
> problems:
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > >    - thread and transaction have hard
> > > related
> > > > > (we
> > > > > > > use
> > > > > > > > >> > > > > thread-local
> > > > > > > > >> > > > > > > > > variable
> > > > > > > > >> > > > > > > > > >    and thread name)
> > > > > > > > >> > > > > > > > > >    - we can process only one transaction
> > at
> > > > the
> > > > > > same
> > > > > > > > >> time
> > > > > > > > >> > in
> > > > > > > > >> > > > one
> > > > > > > > >> > > > > > > thread
> > > > > > > > >> > > > > > > > > (it
> > > > > > > > >> > > > > > > > > >    mean we need hold thread per client.
> If
> > > > > connect
> > > > > > > 100
> > > > > > > > >> thin
> > > > > > > > >> > > > > clients
> > > > > > > > >> > > > > > > to
> > > > > > > > >> > > > > > > > 1
> > > > > > > > >> > > > > > > > > >    server node, then need to hold 100
> > thread
> > > > on
> > > > > > the
> > > > > > > > >> server
> > > > > > > > >> > > > side)
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > Let's discuss how we can implement
> > > > transactions
> > > > > > for
> > > > > > > > the
> > > > > > > > >> > thin
> > > > > > > > >> > > > > > client.
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > --
> > > > > > > > >> > > > > Sergey Kozlov
> > > > > > > > >> > > > > GridGain Systems
> > > > > > > > >> > > > > www.gridgain.com
> > > > > > > > >> > > > >
> > > > > > > > >> > > >
> > > > > > > > >> > >
> > > > > > > > >> >
> > > > > > > > >> >
> > > > > > > > >> > --
> > > > > > > > >> > Sergey Kozlov
> > > > > > > > >> > GridGain Systems
> > > > > > > > >> > www.gridgain.com
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[Alexey Plekhanov]

Guys, so, do we need multiple concurrent transactions per connection?

There are pros and cons for each approach. Difference between approaches:

One transaction at a time per connection:
 - This approach is used in RDBMS world and users got used to it
 - To use transactions concurrently users need to use different connections
and get these connections via something like a connection pool
 - Easy to implement (in fact, PoC is already done)

Multiple concurrent transactions per connection:
 - At least for java thin client, we can implement transaction per thread
approach as implemented now for the thick client (perhaps other thin
clients can implement the same abstraction)
 - There is also protocol change for all cache operations needed (to bind
cache operation to the transaction)
 - Significant changes to all implemented clients are needed
 - Implementation on the server side is more complex

What do you think?


вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <[hidden email]>:

> Ilya,
>
> > We should be able to multiplex several transactions using a single
> Client connection.
> In this case, we should significantly change cache operations syntax (for
> each implemented client), to bind each operation to the transaction.
>
> > I want to also ask if "Number of entries participating in transaction
> (may be approximate). 0 - default value." is needed.
> I've tried to minimize API changes between thick and thin client to
> simplify move from one to another. It's the only reason. But I agree with
> you, the parameter is not very useful.
>
>
> вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <[hidden email]>:
>
>> Hello!
>>
>> Pavel, I agree with you thorougly. We should be able to multiplex several
>> transactions using a single Client connection. This means adding
>> Transaction id parameter to every affected cache operation / SQL statement
>> (if applicable) to make sure we do cache operations on relevant
>> transaction.
>>
>> This is how other things work in Ignite, such as communication. We do not
>> open dozens of connections, we multiplex operations asynchronously through
>> a single connection.
>>
>> I think that trying to pool Ignite connections will be highly
>> inconvenient,
>> since there is no existing infrastructure for such pooling (like there
>> exists for JDBC).
>>
>> I want to also ask if "Number of entries participating in transaction (may
>> be approximate). 0 - default value." is needed. Does it actually do
>> anything in our tx protocol? Users of existing APIs are already confused
>> by
>> this parameter, if we could get rid of it in thin client protocol it would
>> be nice clean-up.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]>:
>>
>> > Alex,
>> >
>> > > now we can only support one active transaction per connection
>> >
>> > I totally understand server-side and protocol limitations that are
>> causing
>> > this.
>> > But I have no idea how to support this in .NET Thin Client, for example.
>> >
>> > It is thread-safe and can handle multiple async operations in parallel.
>> > But with TX support we have to somehow switch to single-threaded mode to
>> > avoid unexpected effects.
>> >
>> > Any ideas?
>> >
>> >
>> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <[hidden email]>
>> > wrote:
>> >
>> > > Dmitriy, thank you!
>> > >
>> > > Guys, I've created the IEP [1] on wiki, please have a look.
>> > >
>> > > [1]
>> > >
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > >
>> > >
>> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <[hidden email]>:
>> > >
>> > > > Hi,
>> > > >
>> > > > I've added permissions to account plehanov.alex
>> > > >
>> > > > Recently Infra integrated Apache LDAP with confluence, so it is
>> > possible
>> > > to
>> > > > login using Apache credentials. Probably we can ask infra if extra
>> > > > permissions to edit pages should be added for committers.
>> > > >
>> > > > Sincerely,
>> > > > Dmitriy Pavlov
>> > > >
>> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <[hidden email]
>> >:
>> > > >
>> > > > > Vladimir,
>> > > > >
>> > > > > About current tx: ok, then we don't need tx() method in the
>> interface
>> > > at
>> > > > > all (the same cached transaction info user can store by himself).
>> > > > >
>> > > > > About decoupling transactions from threads on the server side: for
>> > now,
>> > > > we
>> > > > > can start with thread-per-connection approach (we only can support
>> > one
>> > > > > active transaction per connection, see below, so we need one
>> > additional
>> > > > > dedicated thread for each connection with active transaction), and
>> > > later
>> > > > > change server-side internals to process client transactions in any
>> > > server
>> > > > > thread (not dedicated to this connection). This change will not
>> > affect
>> > > > the
>> > > > > thin client protocol, it only affects the server side.
>> > > > > In any case, we can't support concurrent transactions per
>> connection
>> > on
>> > > > > the client side without fundamental changes to the current
>> protocol
>> > > > (cache
>> > > > > operation doesn't bound to transaction or thread and the server
>> > doesn't
>> > > > > know which thread on the client side do this cache operation). In
>> my
>> > > > > opinion, if a user wants to use concurrent transactions, he must
>> use
>> > > > > different connections from a connection pool.
>> > > > >
>> > > > > About semantics of suspend/resume on the client-side: it's
>> absolutely
>> > > > > different than server-side semantics (we don't need to do
>> > > suspend/resume
>> > > > to
>> > > > > pass transaction between threads on the client-side), but can't be
>> > > > > implemented efficiently without implemented suspend/resume on
>> > > > server-side.
>> > > > >
>> > > > > Can anyone give me permissions to create IEP on Apache wiki?
>> > > > >
>> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
>> [hidden email]>:
>> > > > >
>> > > > > > Hi Alex,
>> > > > > >
>> > > > > > My comments was only about the protocol. Getting current info
>> about
>> > > > > > transaction should be handled by the client itself. It is not
>> > > protocl's
>> > > > > > concern. Same about other APIs and behavior in case another
>> > > transaction
>> > > > > is
>> > > > > > attempted from the same thread.
>> > > > > >
>> > > > > > Putting protocol aside, transaction support is complicated
>> matter.
>> > I
>> > > > > would
>> > > > > > propose to route through IEP and wide community discussion. We
>> need
>> > > to
>> > > > > > review API and semantics very carefully, taking SUSPEND/RESUME
>> in
>> > > > count.
>> > > > > > Also I do not see how we support client transactions efficiently
>> > > > without
>> > > > > > decoupling transactions from threads on the server side first.
>> > > Because
>> > > > > > without it you will need a dedicated server thread for every
>> > client's
>> > > > > > transaction which is slow and may even crash the server.
>> > > > > >
>> > > > > > Vladimir.
>> > > > > >
>> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
>> > > > [hidden email]>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Vladimir, what if we want to get current transaction info
>> (tx()
>> > > > > method)?
>> > > > > > >
>> > > > > > > Does close() method mapped to TX_END(rollback)?
>> > > > > > >
>> > > > > > > For example, this code:
>> > > > > > >
>> > > > > > > try(tx = txStart()) {
>> > > > > > >     tx.commit();
>> > > > > > > }
>> > > > > > >
>> > > > > > > Will produce:
>> > > > > > > TX_START
>> > > > > > > TX_END(commit)
>> > > > > > > TX_END(rollback)
>> > > > > > >
>> > > > > > > Am I understand you right?
>> > > > > > >
>> > > > > > > About xid. There is yet another proposal. Use some unique per
>> > > > > connection
>> > > > > > id
>> > > > > > > (integer, simple counter) for identifying the transaction on
>> > > > > > > commit/rollback message. The client gets this id from the
>> server
>> > > with
>> > > > > > > transaction info and sends it back to the server when trying
>> to
>> > > > > > > commit/rollback transaction. This id is not shown to users.
>> But
>> > > also
>> > > > we
>> > > > > > can
>> > > > > > > pass from server to client real transaction id (xid) with
>> > > transaction
>> > > > > > info
>> > > > > > > for diagnostic purposes.
>> > > > > > >
>> > > > > > > And one more question: what should we do if the client starts
>> a
>> > new
>> > > > > > > transaction without ending the old one? Should we end the old
>> > > > > transaction
>> > > > > > > implicitly (rollback) or throw an exception to the client? In
>> my
>> > > > > opinion,
>> > > > > > > the first option is better. For example, if we got a
>> previously
>> > > used
>> > > > > > > connection from the connection pool, we should not worry about
>> > any
>> > > > > > > uncompleted transaction started by the previous user of this
>> > > > > connection.
>> > > > > > >
>> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
>> > [hidden email]
>> > > >:
>> > > > > > >
>> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support them
>> > yet,
>> > > > and
>> > > > > > > adding
>> > > > > > > > them in future should not conflict with simple START/END
>> > > > > > infrastructure.
>> > > > > > > >
>> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
>> > > > > [hidden email]
>> > > > > > >
>> > > > > > > > wrote:
>> > > > > > > >
>> > > > > > > > > Hi Alex,
>> > > > > > > > >
>> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be enough to
>> > have
>> > > > > only
>> > > > > > > two?
>> > > > > > > > >
>> > > > > > > > > START - accepts optional parameters, returns transaction
>> info
>> > > > > > > > > END - provides commit flag, returns void
>> > > > > > > > >
>> > > > > > > > > Vladimir.
>> > > > > > > > >
>> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
>> > > > > > [hidden email]
>> > > > > > > >
>> > > > > > > > > wrote:
>> > > > > > > > >
>> > > > > > > > >> Sergey, yes, the close is something like silent rollback.
>> > But
>> > > we
>> > > > > can
>> > > > > > > > >> also implement this on the client side, just using
>> rollback
>> > > and
>> > > > > > > ignoring
>> > > > > > > > >> errors in the response.
>> > > > > > > > >>
>> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
>> > > > [hidden email]
>> > > > > >:
>> > > > > > > > >>
>> > > > > > > > >> > Nikolay
>> > > > > > > > >> >
>> > > > > > > > >> > Am I correctly understand you points:
>> > > > > > > > >> >
>> > > > > > > > >> >    - close: rollback
>> > > > > > > > >> >    - commit, close: do nothing
>> > > > > > > > >> >    - rollback, close: do what? (I suppose nothing)
>> > > > > > > > >> >
>> > > > > > > > >> > Also you assume that after commit/rollback we may need
>> to
>> > > free
>> > > > > > some
>> > > > > > > > >> > resources on server node(s)or just do on client started
>> > TX?
>> > > > > > > > >> >
>> > > > > > > > >> >
>> > > > > > > > >> >
>> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
>> > > > > > > > [hidden email]
>> > > > > > > > >> >
>> > > > > > > > >> > wrote:
>> > > > > > > > >> >
>> > > > > > > > >> > > Sergey, we have the close() method in the thick
>> client,
>> > > it's
>> > > > > > > > behavior
>> > > > > > > > >> is
>> > > > > > > > >> > > slightly different than rollback() method (it should
>> > > > rollback
>> > > > > if
>> > > > > > > the
>> > > > > > > > >> > > transaction is not committed and do nothing if the
>> > > > transaction
>> > > > > > is
>> > > > > > > > >> already
>> > > > > > > > >> > > committed). I think we should support
>> try-with-resource
>> > > > > > semantics
>> > > > > > > in
>> > > > > > > > >> the
>> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here.
>> > > > > > > > >> > >
>> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
>> pessimistic
>> > > > > > > > transactions.
>> > > > > > > > >> > Also,
>> > > > > > > > >> > > the main goal of suspend/resume operations is to
>> support
>> > > > > > > transaction
>> > > > > > > > >> > > passing between threads. In the thin client, the
>> > > transaction
>> > > > > is
>> > > > > > > > bound
>> > > > > > > > >> to
>> > > > > > > > >> > > the client connection, not client thread. I think
>> > passing
>> > > a
>> > > > > > > > >> transaction
>> > > > > > > > >> > > between different client connections is not a very
>> > useful
>> > > > > case.
>> > > > > > > > >> > >
>> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov <
>> > > > > > [hidden email]
>> > > > > > > >:
>> > > > > > > > >> > >
>> > > > > > > > >> > > > Hello, Alex.
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > We also have suspend and resume operations.
>> > > > > > > > >> > > > I think we should support them
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
>> > > > > > [hidden email]
>> > > > > > > >:
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > > Hi
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > Looks like I missed something but why we need
>> > > > OP_TX_CLOSE
>> > > > > > > > >> operation?
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > Also I suggest to reserve a code for SAVEPOINT
>> > > operation
>> > > > > > which
>> > > > > > > > >> very
>> > > > > > > > >> > > > useful
>> > > > > > > > >> > > > > to understand where transaction has been rolled
>> back
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
>> > > > > > > > >> > [hidden email]
>> > > > > > > > >> > > >
>> > > > > > > > >> > > > > wrote:
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > > Hello Igniters!
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369 and
>> add
>> > > > > > > transactions
>> > > > > > > > >> > support
>> > > > > > > > >> > > > to
>> > > > > > > > >> > > > > > our thin client implementation.
>> > > > > > > > >> > > > > > I've looked at our current implementation and
>> have
>> > > > some
>> > > > > > > > >> proposals
>> > > > > > > > >> > to
>> > > > > > > > >> > > > > > support transactions:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > Add new operations to thin client protocol:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current transaction
>> for
>> > > > client
>> > > > > > > > >> connection
>> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new transaction
>> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit transaction
>> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback transaction
>> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close transaction
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > From the client side (java) new interfaces
>> will be
>> > > > > added:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > public interface ClientTransactions {
>> > > > > > > > >> > > > > >     public ClientTransaction txStart();
>> > > > > > > > >> > > > > >     public ClientTransaction
>> > > > > > txStart(TransactionConcurrency
>> > > > > > > > >> > > > concurrency,
>> > > > > > > > >> > > > > > TransactionIsolation isolation);
>> > > > > > > > >> > > > > >     public ClientTransaction
>> > > > > > txStart(TransactionConcurrency
>> > > > > > > > >> > > > concurrency,
>> > > > > > > > >> > > > > > TransactionIsolation isolation, long timeout,
>> int
>> > > > > txSize);
>> > > > > > > > >> > > > > >     public ClientTransaction tx(); // Get
>> current
>> > > > > > connection
>> > > > > > > > >> > > > transaction
>> > > > > > > > >> > > > > >     public ClientTransactions withLabel(String
>> > lb);
>> > > > > > > > >> > > > > > }
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > public interface ClientTransaction extends
>> > > > > AutoCloseable {
>> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we need it?
>> > > > > > > > >> > > > > >     public TransactionIsolation isolation();
>> > > > > > > > >> > > > > >     public TransactionConcurrency
>> concurrency();
>> > > > > > > > >> > > > > >     public long timeout();
>> > > > > > > > >> > > > > >     public String label();
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > >     public void commit();
>> > > > > > > > >> > > > > >     public void rollback();
>> > > > > > > > >> > > > > >     public void close();
>> > > > > > > > >> > > > > > }
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > From the server side, I think as a first step
>> > (while
>> > > > > > > > >> transactions
>> > > > > > > > >> > > > > > suspend/resume is not fully implemented) we can
>> > use
>> > > > the
>> > > > > > same
>> > > > > > > > >> > approach
>> > > > > > > > >> > > > as
>> > > > > > > > >> > > > > > for JDBC: add a new worker to each
>> > > > ClientRequestHandler
>> > > > > > and
>> > > > > > > > >> process
>> > > > > > > > >> > > > > > requests by this worker if the transaction is
>> > > started
>> > > > > > > > >> explicitly.
>> > > > > > > > >> > > > > > ClientRequestHandler is bound to client
>> > connection,
>> > > so
>> > > > > > there
>> > > > > > > > >> will
>> > > > > > > > >> > be
>> > > > > > > > >> > > > 1:1
>> > > > > > > > >> > > > > > relation between client connection and thread,
>> > which
>> > > > > > process
>> > > > > > > > >> > > operations
>> > > > > > > > >> > > > > in
>> > > > > > > > >> > > > > > a transaction.
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > Also, there is a couple of issues I want to
>> > discuss:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > We have overloaded method txStart with a
>> different
>> > > set
>> > > > > of
>> > > > > > > > >> > arguments.
>> > > > > > > > >> > > > Some
>> > > > > > > > >> > > > > > of the arguments may be missing. To pass
>> arguments
>> > > > with
>> > > > > > > > >> OP_TX_START
>> > > > > > > > >> > > > > > operation we have the next options:
>> > > > > > > > >> > > > > >  * Serialize full set of arguments and use some
>> > > value
>> > > > > for
>> > > > > > > > >> missing
>> > > > > > > > >> > > > > > arguments. For example -1 for int/long types
>> and
>> > > null
>> > > > > for
>> > > > > > > > string
>> > > > > > > > >> > > type.
>> > > > > > > > >> > > > We
>> > > > > > > > >> > > > > > can't use 0 for int/long types since 0 it's a
>> > valid
>> > > > > value
>> > > > > > > for
>> > > > > > > > >> > > > > concurrency,
>> > > > > > > > >> > > > > > isolation and timeout arguments.
>> > > > > > > > >> > > > > >  * Serialize arguments as a collection of
>> > > > property-value
>> > > > > > > pairs
>> > > > > > > > >> > (like
>> > > > > > > > >> > > > it's
>> > > > > > > > >> > > > > > implemented now for CacheConfiguration). In
>> this
>> > > case
>> > > > > only
>> > > > > > > > >> > explicitly
>> > > > > > > > >> > > > > > provided arguments will be serialized.
>> > > > > > > > >> > > > > > Which way is better? The simplest solution is
>> to
>> > use
>> > > > the
>> > > > > > > first
>> > > > > > > > >> > option
>> > > > > > > > >> > > > > and I
>> > > > > > > > >> > > > > > want to use it if there were no objections.
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > Do we need transaction id (xid) on the client
>> > side?
>> > > > > > > > >> > > > > > If yes, we can pass xid along with
>> OP_TX_COMMIT,
>> > > > > > > > OP_TX_ROLLBACK,
>> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server and
>> do
>> > > > > > additional
>> > > > > > > > >> check
>> > > > > > > > >> > on
>> > > > > > > > >> > > > the
>> > > > > > > > >> > > > > > server side (current transaction id for
>> connection
>> > > ==
>> > > > > > > > >> transaction
>> > > > > > > > >> > id
>> > > > > > > > >> > > > > passed
>> > > > > > > > >> > > > > > from client side). This, perhaps, will protect
>> > > clients
>> > > > > > > against
>> > > > > > > > >> some
>> > > > > > > > >> > > > > errors
>> > > > > > > > >> > > > > > (for example when client try to commit outdated
>> > > > > > > transaction).
>> > > > > > > > >> But
>> > > > > > > > >> > > > > > currently, we don't have data type IgniteUuid
>> in
>> > > thin
>> > > > > > client
>> > > > > > > > >> > > protocol.
>> > > > > > > > >> > > > Do
>> > > > > > > > >> > > > > > we need to add it too?
>> > > > > > > > >> > > > > > Also, we can pass xid as a string just to
>> inform
>> > the
>> > > > > > client
>> > > > > > > > and
>> > > > > > > > >> do
>> > > > > > > > >> > > not
>> > > > > > > > >> > > > > pass
>> > > > > > > > >> > > > > > it back to the server with commit/rollback
>> > > operation.
>> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick client
>> works
>> > > > this
>> > > > > > way
>> > > > > > > as
>> > > > > > > > >> far
>> > > > > > > > >> > > as I
>> > > > > > > > >> > > > > > know).
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > What do you think?
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir Ozerov <
>> > > > > > > > >> [hidden email]
>> > > > > > > > >> > >:
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > > > > We already have transactions support in JDBC
>> > > driver
>> > > > in
>> > > > > > TX
>> > > > > > > > SQL
>> > > > > > > > >> > > branch
>> > > > > > > > >> > > > > > > (ignite-4191). Currently it is implemented
>> > through
>> > > > > > > separate
>> > > > > > > > >> > thread,
>> > > > > > > > >> > > > > which
>> > > > > > > > >> > > > > > > is not that efficient. Ideally we need to
>> finish
>> > > > > > > decoupling
>> > > > > > > > >> > > > > transactions
>> > > > > > > > >> > > > > > > from threads. But alternatively we can change
>> > the
>> > > > > logic
>> > > > > > on
>> > > > > > > > >> how we
>> > > > > > > > >> > > > > assign
>> > > > > > > > >> > > > > > > thread ID to specific transaction and
>> > > "impersonate"
>> > > > > thin
>> > > > > > > > >> client
>> > > > > > > > >> > > > worker
>> > > > > > > > >> > > > > > > threads when serving requests from multiple
>> > users.
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis Magda
>> <
>> > > > > > > > >> [hidden email]>
>> > > > > > > > >> > > > > wrote:
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > > > > Here is an original discussion with a
>> > reference
>> > > to
>> > > > > the
>> > > > > > > > JIRA
>> > > > > > > > >> > > ticket:
>> > > > > > > > >> > > > > > > >
>> > > http://apache-ignite-developers.2346864.n4.nabble
>> > > > .
>> > > > > > > > >> > > > > > > >
>> > > > > > > > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
>> > > > > > > > >> > > > > > > > Protocol-td25914.html
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > > > --
>> > > > > > > > >> > > > > > > > Denis
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy
>> > > Setrakyan
>> > > > <
>> > > > > > > > >> > > > > > [hidden email]
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > > > wrote:
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a
>> design
>> > > > > proposal
>> > > > > > > for
>> > > > > > > > >> > > > transaction
>> > > > > > > > >> > > > > > > > support
>> > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking this
>> > > > > initiative
>> > > > > > > and
>> > > > > > > > >> > > creating
>> > > > > > > > >> > > > an
>> > > > > > > > >> > > > > > IEP
>> > > > > > > > >> > > > > > > > on
>> > > > > > > > >> > > > > > > > > Wiki?
>> > > > > > > > >> > > > > > > > >
>> > > > > > > > >> > > > > > > > > D.
>> > > > > > > > >> > > > > > > > >
>> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy
>> > > > > Govorukhin <
>> > > > > > > > >> > > > > > > > > [hidden email]> wrote:
>> > > > > > > > >> > > > > > > > >
>> > > > > > > > >> > > > > > > > > > Hi, Igniters.
>> > > > > > > > >> > > > > > > > > >
>> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions about
>> thin
>> > > > client
>> > > > > > and
>> > > > > > > > >> binary
>> > > > > > > > >> > > > > > protocol,
>> > > > > > > > >> > > > > > > > > but I
>> > > > > > > > >> > > > > > > > > > did not hear anything about
>> transactions
>> > > > > support.
>> > > > > > Do
>> > > > > > > > we
>> > > > > > > > >> > have
>> > > > > > > > >> > > > some
>> > > > > > > > >> > > > > > > draft
>> > > > > > > > >> > > > > > > > > for
>> > > > > > > > >> > > > > > > > > > this purpose?
>> > > > > > > > >> > > > > > > > > >
>> > > > > > > > >> > > > > > > > > > As I understand we have several
>> problems:
>> > > > > > > > >> > > > > > > > > >
>> > > > > > > > >> > > > > > > > > >    - thread and transaction have hard
>> > > related
>> > > > > (we
>> > > > > > > use
>> > > > > > > > >> > > > > thread-local
>> > > > > > > > >> > > > > > > > > variable
>> > > > > > > > >> > > > > > > > > >    and thread name)
>> > > > > > > > >> > > > > > > > > >    - we can process only one
>> transaction
>> > at
>> > > > the
>> > > > > > same
>> > > > > > > > >> time
>> > > > > > > > >> > in
>> > > > > > > > >> > > > one
>> > > > > > > > >> > > > > > > thread
>> > > > > > > > >> > > > > > > > > (it
>> > > > > > > > >> > > > > > > > > >    mean we need hold thread per
>> client. If
>> > > > > connect
>> > > > > > > 100
>> > > > > > > > >> thin
>> > > > > > > > >> > > > > clients
>> > > > > > > > >> > > > > > > to
>> > > > > > > > >> > > > > > > > 1
>> > > > > > > > >> > > > > > > > > >    server node, then need to hold 100
>> > thread
>> > > > on
>> > > > > > the
>> > > > > > > > >> server
>> > > > > > > > >> > > > side)
>> > > > > > > > >> > > > > > > > > >
>> > > > > > > > >> > > > > > > > > > Let's discuss how we can implement
>> > > > transactions
>> > > > > > for
>> > > > > > > > the
>> > > > > > > > >> > thin
>> > > > > > > > >> > > > > > client.
>> > > > > > > > >> > > > > > > > > >
>> > > > > > > > >> > > > > > > > >
>> > > > > > > > >> > > > > > > >
>> > > > > > > > >> > > > > > >
>> > > > > > > > >> > > > > >
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > > > --
>> > > > > > > > >> > > > > Sergey Kozlov
>> > > > > > > > >> > > > > GridGain Systems
>> > > > > > > > >> > > > > www.gridgain.com
>> > > > > > > > >> > > > >
>> > > > > > > > >> > > >
>> > > > > > > > >> > >
>> > > > > > > > >> >
>> > > > > > > > >> >
>> > > > > > > > >> > --
>> > > > > > > > >> > Sergey Kozlov
>> > > > > > > > >> > GridGain Systems
>> > > > > > > > >> > www.gridgain.com
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>

[Vladimir Ozerov]

Hi Alex,

I think we should be able to handle many transactions through a single
connection. This will make our protocol and client implementations much
more efficient, and simplicity from developer's perspective is not our
goal. Consider normal nodes. We have server nodes and client nodes. You may
span whatever number of transactions you need, but all of them are
coordinated through a single connection. The same should be applicable to
thin clients. Protocol is already designed to handle this, as we pass
unique operation ID in order to distinguish one operation from another. It
is true, though, that we will have to introduce a kind of "session"
concept, and pass additional identifier along with cache operations, but
this doesn't sound like a problem to me.

And provided that currently server-side transactions are bound to threads
artificially, I would say that the first step in implementation of
transactions on thin clients should be decoupling server-side transactions
from threads. Without this we will have very inefficient implementation,
when every new client transaction have to spawn a new thread. This is slow
and introduces high memory pressure on a cluster node. We already work this
way for MVCC transactions which are spawned from JDBC driver, and believe
me, we do not want to replicated this bad practice to other clients :-)

Vladimir.

On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <[hidden email]>
wrote:

> Guys, so, do we need multiple concurrent transactions per connection?
>
> There are pros and cons for each approach. Difference between approaches:
>
> One transaction at a time per connection:
>  - This approach is used in RDBMS world and users got used to it
>  - To use transactions concurrently users need to use different connections
> and get these connections via something like a connection pool
>  - Easy to implement (in fact, PoC is already done)
>
> Multiple concurrent transactions per connection:
>  - At least for java thin client, we can implement transaction per thread
> approach as implemented now for the thick client (perhaps other thin
> clients can implement the same abstraction)
>  - There is also protocol change for all cache operations needed (to bind
> cache operation to the transaction)
>  - Significant changes to all implemented clients are needed
>  - Implementation on the server side is more complex
>
> What do you think?
>
>
> вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <[hidden email]>:
>
> > Ilya,
> >
> > > We should be able to multiplex several transactions using a single
> > Client connection.
> > In this case, we should significantly change cache operations syntax (for
> > each implemented client), to bind each operation to the transaction.
> >
> > > I want to also ask if "Number of entries participating in transaction
> > (may be approximate). 0 - default value." is needed.
> > I've tried to minimize API changes between thick and thin client to
> > simplify move from one to another. It's the only reason. But I agree with
> > you, the parameter is not very useful.
> >
> >
> > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <[hidden email]>:
> >
> >> Hello!
> >>
> >> Pavel, I agree with you thorougly. We should be able to multiplex
> several
> >> transactions using a single Client connection. This means adding
> >> Transaction id parameter to every affected cache operation / SQL
> statement
> >> (if applicable) to make sure we do cache operations on relevant
> >> transaction.
> >>
> >> This is how other things work in Ignite, such as communication. We do
> not
> >> open dozens of connections, we multiplex operations asynchronously
> through
> >> a single connection.
> >>
> >> I think that trying to pool Ignite connections will be highly
> >> inconvenient,
> >> since there is no existing infrastructure for such pooling (like there
> >> exists for JDBC).
> >>
> >> I want to also ask if "Number of entries participating in transaction
> (may
> >> be approximate). 0 - default value." is needed. Does it actually do
> >> anything in our tx protocol? Users of existing APIs are already confused
> >> by
> >> this parameter, if we could get rid of it in thin client protocol it
> would
> >> be nice clean-up.
> >>
> >> Regards,
> >> --
> >> Ilya Kasnacheev
> >>
> >>
> >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]>:
> >>
> >> > Alex,
> >> >
> >> > > now we can only support one active transaction per connection
> >> >
> >> > I totally understand server-side and protocol limitations that are
> >> causing
> >> > this.
> >> > But I have no idea how to support this in .NET Thin Client, for
> example.
> >> >
> >> > It is thread-safe and can handle multiple async operations in
> parallel.
> >> > But with TX support we have to somehow switch to single-threaded mode
> to
> >> > avoid unexpected effects.
> >> >
> >> > Any ideas?
> >> >
> >> >
> >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <[hidden email]
> >
> >> > wrote:
> >> >
> >> > > Dmitriy, thank you!
> >> > >
> >> > > Guys, I've created the IEP [1] on wiki, please have a look.
> >> > >
> >> > > [1]
> >> > >
> >> > >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >> > >
> >> > >
> >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <[hidden email]>:
> >> > >
> >> > > > Hi,
> >> > > >
> >> > > > I've added permissions to account plehanov.alex
> >> > > >
> >> > > > Recently Infra integrated Apache LDAP with confluence, so it is
> >> > possible
> >> > > to
> >> > > > login using Apache credentials. Probably we can ask infra if extra
> >> > > > permissions to edit pages should be added for committers.
> >> > > >
> >> > > > Sincerely,
> >> > > > Dmitriy Pavlov
> >> > > >
> >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
> [hidden email]
> >> >:
> >> > > >
> >> > > > > Vladimir,
> >> > > > >
> >> > > > > About current tx: ok, then we don't need tx() method in the
> >> interface
> >> > > at
> >> > > > > all (the same cached transaction info user can store by
> himself).
> >> > > > >
> >> > > > > About decoupling transactions from threads on the server side:
> for
> >> > now,
> >> > > > we
> >> > > > > can start with thread-per-connection approach (we only can
> support
> >> > one
> >> > > > > active transaction per connection, see below, so we need one
> >> > additional
> >> > > > > dedicated thread for each connection with active transaction),
> and
> >> > > later
> >> > > > > change server-side internals to process client transactions in
> any
> >> > > server
> >> > > > > thread (not dedicated to this connection). This change will not
> >> > affect
> >> > > > the
> >> > > > > thin client protocol, it only affects the server side.
> >> > > > > In any case, we can't support concurrent transactions per
> >> connection
> >> > on
> >> > > > > the client side without fundamental changes to the current
> >> protocol
> >> > > > (cache
> >> > > > > operation doesn't bound to transaction or thread and the server
> >> > doesn't
> >> > > > > know which thread on the client side do this cache operation).
> In
> >> my
> >> > > > > opinion, if a user wants to use concurrent transactions, he must
> >> use
> >> > > > > different connections from a connection pool.
> >> > > > >
> >> > > > > About semantics of suspend/resume on the client-side: it's
> >> absolutely
> >> > > > > different than server-side semantics (we don't need to do
> >> > > suspend/resume
> >> > > > to
> >> > > > > pass transaction between threads on the client-side), but can't
> be
> >> > > > > implemented efficiently without implemented suspend/resume on
> >> > > > server-side.
> >> > > > >
> >> > > > > Can anyone give me permissions to create IEP on Apache wiki?
> >> > > > >
> >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
> >> [hidden email]>:
> >> > > > >
> >> > > > > > Hi Alex,
> >> > > > > >
> >> > > > > > My comments was only about the protocol. Getting current info
> >> about
> >> > > > > > transaction should be handled by the client itself. It is not
> >> > > protocl's
> >> > > > > > concern. Same about other APIs and behavior in case another
> >> > > transaction
> >> > > > > is
> >> > > > > > attempted from the same thread.
> >> > > > > >
> >> > > > > > Putting protocol aside, transaction support is complicated
> >> matter.
> >> > I
> >> > > > > would
> >> > > > > > propose to route through IEP and wide community discussion. We
> >> need
> >> > > to
> >> > > > > > review API and semantics very carefully, taking SUSPEND/RESUME
> >> in
> >> > > > count.
> >> > > > > > Also I do not see how we support client transactions
> efficiently
> >> > > > without
> >> > > > > > decoupling transactions from threads on the server side first.
> >> > > Because
> >> > > > > > without it you will need a dedicated server thread for every
> >> > client's
> >> > > > > > transaction which is slow and may even crash the server.
> >> > > > > >
> >> > > > > > Vladimir.
> >> > > > > >
> >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> >> > > > [hidden email]>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Vladimir, what if we want to get current transaction info
> >> (tx()
> >> > > > > method)?
> >> > > > > > >
> >> > > > > > > Does close() method mapped to TX_END(rollback)?
> >> > > > > > >
> >> > > > > > > For example, this code:
> >> > > > > > >
> >> > > > > > > try(tx = txStart()) {
> >> > > > > > >     tx.commit();
> >> > > > > > > }
> >> > > > > > >
> >> > > > > > > Will produce:
> >> > > > > > > TX_START
> >> > > > > > > TX_END(commit)
> >> > > > > > > TX_END(rollback)
> >> > > > > > >
> >> > > > > > > Am I understand you right?
> >> > > > > > >
> >> > > > > > > About xid. There is yet another proposal. Use some unique
> per
> >> > > > > connection
> >> > > > > > id
> >> > > > > > > (integer, simple counter) for identifying the transaction on
> >> > > > > > > commit/rollback message. The client gets this id from the
> >> server
> >> > > with
> >> > > > > > > transaction info and sends it back to the server when trying
> >> to
> >> > > > > > > commit/rollback transaction. This id is not shown to users.
> >> But
> >> > > also
> >> > > > we
> >> > > > > > can
> >> > > > > > > pass from server to client real transaction id (xid) with
> >> > > transaction
> >> > > > > > info
> >> > > > > > > for diagnostic purposes.
> >> > > > > > >
> >> > > > > > > And one more question: what should we do if the client
> starts
> >> a
> >> > new
> >> > > > > > > transaction without ending the old one? Should we end the
> old
> >> > > > > transaction
> >> > > > > > > implicitly (rollback) or throw an exception to the client?
> In
> >> my
> >> > > > > opinion,
> >> > > > > > > the first option is better. For example, if we got a
> >> previously
> >> > > used
> >> > > > > > > connection from the connection pool, we should not worry
> about
> >> > any
> >> > > > > > > uncompleted transaction started by the previous user of this
> >> > > > > connection.
> >> > > > > > >
> >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> >> > [hidden email]
> >> > > >:
> >> > > > > > >
> >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support
> them
> >> > yet,
> >> > > > and
> >> > > > > > > adding
> >> > > > > > > > them in future should not conflict with simple START/END
> >> > > > > > infrastructure.
> >> > > > > > > >
> >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> >> > > > > [hidden email]
> >> > > > > > >
> >> > > > > > > > wrote:
> >> > > > > > > >
> >> > > > > > > > > Hi Alex,
> >> > > > > > > > >
> >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be enough
> to
> >> > have
> >> > > > > only
> >> > > > > > > two?
> >> > > > > > > > >
> >> > > > > > > > > START - accepts optional parameters, returns transaction
> >> info
> >> > > > > > > > > END - provides commit flag, returns void
> >> > > > > > > > >
> >> > > > > > > > > Vladimir.
> >> > > > > > > > >
> >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> >> > > > > > [hidden email]
> >> > > > > > > >
> >> > > > > > > > > wrote:
> >> > > > > > > > >
> >> > > > > > > > >> Sergey, yes, the close is something like silent
> rollback.
> >> > But
> >> > > we
> >> > > > > can
> >> > > > > > > > >> also implement this on the client side, just using
> >> rollback
> >> > > and
> >> > > > > > > ignoring
> >> > > > > > > > >> errors in the response.
> >> > > > > > > > >>
> >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> >> > > > [hidden email]
> >> > > > > >:
> >> > > > > > > > >>
> >> > > > > > > > >> > Nikolay
> >> > > > > > > > >> >
> >> > > > > > > > >> > Am I correctly understand you points:
> >> > > > > > > > >> >
> >> > > > > > > > >> >    - close: rollback
> >> > > > > > > > >> >    - commit, close: do nothing
> >> > > > > > > > >> >    - rollback, close: do what? (I suppose nothing)
> >> > > > > > > > >> >
> >> > > > > > > > >> > Also you assume that after commit/rollback we may
> need
> >> to
> >> > > free
> >> > > > > > some
> >> > > > > > > > >> > resources on server node(s)or just do on client
> started
> >> > TX?
> >> > > > > > > > >> >
> >> > > > > > > > >> >
> >> > > > > > > > >> >
> >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
> >> > > > > > > > [hidden email]
> >> > > > > > > > >> >
> >> > > > > > > > >> > wrote:
> >> > > > > > > > >> >
> >> > > > > > > > >> > > Sergey, we have the close() method in the thick
> >> client,
> >> > > it's
> >> > > > > > > > behavior
> >> > > > > > > > >> is
> >> > > > > > > > >> > > slightly different than rollback() method (it
> should
> >> > > > rollback
> >> > > > > if
> >> > > > > > > the
> >> > > > > > > > >> > > transaction is not committed and do nothing if the
> >> > > > transaction
> >> > > > > > is
> >> > > > > > > > >> already
> >> > > > > > > > >> > > committed). I think we should support
> >> try-with-resource
> >> > > > > > semantics
> >> > > > > > > in
> >> > > > > > > > >> the
> >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here.
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
> >> pessimistic
> >> > > > > > > > transactions.
> >> > > > > > > > >> > Also,
> >> > > > > > > > >> > > the main goal of suspend/resume operations is to
> >> support
> >> > > > > > > transaction
> >> > > > > > > > >> > > passing between threads. In the thin client, the
> >> > > transaction
> >> > > > > is
> >> > > > > > > > bound
> >> > > > > > > > >> to
> >> > > > > > > > >> > > the client connection, not client thread. I think
> >> > passing
> >> > > a
> >> > > > > > > > >> transaction
> >> > > > > > > > >> > > between different client connections is not a very
> >> > useful
> >> > > > > case.
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov <
> >> > > > > > [hidden email]
> >> > > > > > > >:
> >> > > > > > > > >> > >
> >> > > > > > > > >> > > > Hello, Alex.
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > We also have suspend and resume operations.
> >> > > > > > > > >> > > > I think we should support them
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> >> > > > > > [hidden email]
> >> > > > > > > >:
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > > Hi
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > Looks like I missed something but why we need
> >> > > > OP_TX_CLOSE
> >> > > > > > > > >> operation?
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > Also I suggest to reserve a code for SAVEPOINT
> >> > > operation
> >> > > > > > which
> >> > > > > > > > >> very
> >> > > > > > > > >> > > > useful
> >> > > > > > > > >> > > > > to understand where transaction has been rolled
> >> back
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex Plehanov <
> >> > > > > > > > >> > [hidden email]
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > > > > wrote:
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > > Hello Igniters!
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369 and
> >> add
> >> > > > > > > transactions
> >> > > > > > > > >> > support
> >> > > > > > > > >> > > > to
> >> > > > > > > > >> > > > > > our thin client implementation.
> >> > > > > > > > >> > > > > > I've looked at our current implementation and
> >> have
> >> > > > some
> >> > > > > > > > >> proposals
> >> > > > > > > > >> > to
> >> > > > > > > > >> > > > > > support transactions:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > Add new operations to thin client protocol:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current transaction
> >> for
> >> > > > client
> >> > > > > > > > >> connection
> >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
> transaction
> >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit transaction
> >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
> transaction
> >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close transaction
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > From the client side (java) new interfaces
> >> will be
> >> > > > > added:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > public interface ClientTransactions {
> >> > > > > > > > >> > > > > >     public ClientTransaction txStart();
> >> > > > > > > > >> > > > > >     public ClientTransaction
> >> > > > > > txStart(TransactionConcurrency
> >> > > > > > > > >> > > > concurrency,
> >> > > > > > > > >> > > > > > TransactionIsolation isolation);
> >> > > > > > > > >> > > > > >     public ClientTransaction
> >> > > > > > txStart(TransactionConcurrency
> >> > > > > > > > >> > > > concurrency,
> >> > > > > > > > >> > > > > > TransactionIsolation isolation, long timeout,
> >> int
> >> > > > > txSize);
> >> > > > > > > > >> > > > > >     public ClientTransaction tx(); // Get
> >> current
> >> > > > > > connection
> >> > > > > > > > >> > > > transaction
> >> > > > > > > > >> > > > > >     public ClientTransactions
> withLabel(String
> >> > lb);
> >> > > > > > > > >> > > > > > }
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > public interface ClientTransaction extends
> >> > > > > AutoCloseable {
> >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we need
> it?
> >> > > > > > > > >> > > > > >     public TransactionIsolation isolation();
> >> > > > > > > > >> > > > > >     public TransactionConcurrency
> >> concurrency();
> >> > > > > > > > >> > > > > >     public long timeout();
> >> > > > > > > > >> > > > > >     public String label();
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > >     public void commit();
> >> > > > > > > > >> > > > > >     public void rollback();
> >> > > > > > > > >> > > > > >     public void close();
> >> > > > > > > > >> > > > > > }
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > From the server side, I think as a first step
> >> > (while
> >> > > > > > > > >> transactions
> >> > > > > > > > >> > > > > > suspend/resume is not fully implemented) we
> can
> >> > use
> >> > > > the
> >> > > > > > same
> >> > > > > > > > >> > approach
> >> > > > > > > > >> > > > as
> >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> >> > > > ClientRequestHandler
> >> > > > > > and
> >> > > > > > > > >> process
> >> > > > > > > > >> > > > > > requests by this worker if the transaction is
> >> > > started
> >> > > > > > > > >> explicitly.
> >> > > > > > > > >> > > > > > ClientRequestHandler is bound to client
> >> > connection,
> >> > > so
> >> > > > > > there
> >> > > > > > > > >> will
> >> > > > > > > > >> > be
> >> > > > > > > > >> > > > 1:1
> >> > > > > > > > >> > > > > > relation between client connection and
> thread,
> >> > which
> >> > > > > > process
> >> > > > > > > > >> > > operations
> >> > > > > > > > >> > > > > in
> >> > > > > > > > >> > > > > > a transaction.
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > Also, there is a couple of issues I want to
> >> > discuss:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > We have overloaded method txStart with a
> >> different
> >> > > set
> >> > > > > of
> >> > > > > > > > >> > arguments.
> >> > > > > > > > >> > > > Some
> >> > > > > > > > >> > > > > > of the arguments may be missing. To pass
> >> arguments
> >> > > > with
> >> > > > > > > > >> OP_TX_START
> >> > > > > > > > >> > > > > > operation we have the next options:
> >> > > > > > > > >> > > > > >  * Serialize full set of arguments and use
> some
> >> > > value
> >> > > > > for
> >> > > > > > > > >> missing
> >> > > > > > > > >> > > > > > arguments. For example -1 for int/long types
> >> and
> >> > > null
> >> > > > > for
> >> > > > > > > > string
> >> > > > > > > > >> > > type.
> >> > > > > > > > >> > > > We
> >> > > > > > > > >> > > > > > can't use 0 for int/long types since 0 it's a
> >> > valid
> >> > > > > value
> >> > > > > > > for
> >> > > > > > > > >> > > > > concurrency,
> >> > > > > > > > >> > > > > > isolation and timeout arguments.
> >> > > > > > > > >> > > > > >  * Serialize arguments as a collection of
> >> > > > property-value
> >> > > > > > > pairs
> >> > > > > > > > >> > (like
> >> > > > > > > > >> > > > it's
> >> > > > > > > > >> > > > > > implemented now for CacheConfiguration). In
> >> this
> >> > > case
> >> > > > > only
> >> > > > > > > > >> > explicitly
> >> > > > > > > > >> > > > > > provided arguments will be serialized.
> >> > > > > > > > >> > > > > > Which way is better? The simplest solution is
> >> to
> >> > use
> >> > > > the
> >> > > > > > > first
> >> > > > > > > > >> > option
> >> > > > > > > > >> > > > > and I
> >> > > > > > > > >> > > > > > want to use it if there were no objections.
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > Do we need transaction id (xid) on the client
> >> > side?
> >> > > > > > > > >> > > > > > If yes, we can pass xid along with
> >> OP_TX_COMMIT,
> >> > > > > > > > OP_TX_ROLLBACK,
> >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server and
> >> do
> >> > > > > > additional
> >> > > > > > > > >> check
> >> > > > > > > > >> > on
> >> > > > > > > > >> > > > the
> >> > > > > > > > >> > > > > > server side (current transaction id for
> >> connection
> >> > > ==
> >> > > > > > > > >> transaction
> >> > > > > > > > >> > id
> >> > > > > > > > >> > > > > passed
> >> > > > > > > > >> > > > > > from client side). This, perhaps, will
> protect
> >> > > clients
> >> > > > > > > against
> >> > > > > > > > >> some
> >> > > > > > > > >> > > > > errors
> >> > > > > > > > >> > > > > > (for example when client try to commit
> outdated
> >> > > > > > > transaction).
> >> > > > > > > > >> But
> >> > > > > > > > >> > > > > > currently, we don't have data type IgniteUuid
> >> in
> >> > > thin
> >> > > > > > client
> >> > > > > > > > >> > > protocol.
> >> > > > > > > > >> > > > Do
> >> > > > > > > > >> > > > > > we need to add it too?
> >> > > > > > > > >> > > > > > Also, we can pass xid as a string just to
> >> inform
> >> > the
> >> > > > > > client
> >> > > > > > > > and
> >> > > > > > > > >> do
> >> > > > > > > > >> > > not
> >> > > > > > > > >> > > > > pass
> >> > > > > > > > >> > > > > > it back to the server with commit/rollback
> >> > > operation.
> >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick client
> >> works
> >> > > > this
> >> > > > > > way
> >> > > > > > > as
> >> > > > > > > > >> far
> >> > > > > > > > >> > > as I
> >> > > > > > > > >> > > > > > know).
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > What do you think?
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir Ozerov <
> >> > > > > > > > >> [hidden email]
> >> > > > > > > > >> > >:
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > > > > We already have transactions support in
> JDBC
> >> > > driver
> >> > > > in
> >> > > > > > TX
> >> > > > > > > > SQL
> >> > > > > > > > >> > > branch
> >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is implemented
> >> > through
> >> > > > > > > separate
> >> > > > > > > > >> > thread,
> >> > > > > > > > >> > > > > which
> >> > > > > > > > >> > > > > > > is not that efficient. Ideally we need to
> >> finish
> >> > > > > > > decoupling
> >> > > > > > > > >> > > > > transactions
> >> > > > > > > > >> > > > > > > from threads. But alternatively we can
> change
> >> > the
> >> > > > > logic
> >> > > > > > on
> >> > > > > > > > >> how we
> >> > > > > > > > >> > > > > assign
> >> > > > > > > > >> > > > > > > thread ID to specific transaction and
> >> > > "impersonate"
> >> > > > > thin
> >> > > > > > > > >> client
> >> > > > > > > > >> > > > worker
> >> > > > > > > > >> > > > > > > threads when serving requests from multiple
> >> > users.
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis
> Magda
> >> <
> >> > > > > > > > >> [hidden email]>
> >> > > > > > > > >> > > > > wrote:
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > > > > Here is an original discussion with a
> >> > reference
> >> > > to
> >> > > > > the
> >> > > > > > > > JIRA
> >> > > > > > > > >> > > ticket:
> >> > > > > > > > >> > > > > > > >
> >> > > http://apache-ignite-developers.2346864.n4.nabble
> >> > > > .
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > >
> com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> >> > > > > > > > >> > > > > > > > Protocol-td25914.html
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > > > --
> >> > > > > > > > >> > > > > > > > Denis
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy
> >> > > Setrakyan
> >> > > > <
> >> > > > > > > > >> > > > > > [hidden email]
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > > > wrote:
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a
> >> design
> >> > > > > proposal
> >> > > > > > > for
> >> > > > > > > > >> > > > transaction
> >> > > > > > > > >> > > > > > > > support
> >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking
> this
> >> > > > > initiative
> >> > > > > > > and
> >> > > > > > > > >> > > creating
> >> > > > > > > > >> > > > an
> >> > > > > > > > >> > > > > > IEP
> >> > > > > > > > >> > > > > > > > on
> >> > > > > > > > >> > > > > > > > > Wiki?
> >> > > > > > > > >> > > > > > > > >
> >> > > > > > > > >> > > > > > > > > D.
> >> > > > > > > > >> > > > > > > > >
> >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM, Dmitriy
> >> > > > > Govorukhin <
> >> > > > > > > > >> > > > > > > > > [hidden email]> wrote:
> >> > > > > > > > >> > > > > > > > >
> >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> >> > > > > > > > >> > > > > > > > > >
> >> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions about
> >> thin
> >> > > > client
> >> > > > > > and
> >> > > > > > > > >> binary
> >> > > > > > > > >> > > > > > protocol,
> >> > > > > > > > >> > > > > > > > > but I
> >> > > > > > > > >> > > > > > > > > > did not hear anything about
> >> transactions
> >> > > > > support.
> >> > > > > > Do
> >> > > > > > > > we
> >> > > > > > > > >> > have
> >> > > > > > > > >> > > > some
> >> > > > > > > > >> > > > > > > draft
> >> > > > > > > > >> > > > > > > > > for
> >> > > > > > > > >> > > > > > > > > > this purpose?
> >> > > > > > > > >> > > > > > > > > >
> >> > > > > > > > >> > > > > > > > > > As I understand we have several
> >> problems:
> >> > > > > > > > >> > > > > > > > > >
> >> > > > > > > > >> > > > > > > > > >    - thread and transaction have hard
> >> > > related
> >> > > > > (we
> >> > > > > > > use
> >> > > > > > > > >> > > > > thread-local
> >> > > > > > > > >> > > > > > > > > variable
> >> > > > > > > > >> > > > > > > > > >    and thread name)
> >> > > > > > > > >> > > > > > > > > >    - we can process only one
> >> transaction
> >> > at
> >> > > > the
> >> > > > > > same
> >> > > > > > > > >> time
> >> > > > > > > > >> > in
> >> > > > > > > > >> > > > one
> >> > > > > > > > >> > > > > > > thread
> >> > > > > > > > >> > > > > > > > > (it
> >> > > > > > > > >> > > > > > > > > >    mean we need hold thread per
> >> client. If
> >> > > > > connect
> >> > > > > > > 100
> >> > > > > > > > >> thin
> >> > > > > > > > >> > > > > clients
> >> > > > > > > > >> > > > > > > to
> >> > > > > > > > >> > > > > > > > 1
> >> > > > > > > > >> > > > > > > > > >    server node, then need to hold 100
> >> > thread
> >> > > > on
> >> > > > > > the
> >> > > > > > > > >> server
> >> > > > > > > > >> > > > side)
> >> > > > > > > > >> > > > > > > > > >
> >> > > > > > > > >> > > > > > > > > > Let's discuss how we can implement
> >> > > > transactions
> >> > > > > > for
> >> > > > > > > > the
> >> > > > > > > > >> > thin
> >> > > > > > > > >> > > > > > client.
> >> > > > > > > > >> > > > > > > > > >
> >> > > > > > > > >> > > > > > > > >
> >> > > > > > > > >> > > > > > > >
> >> > > > > > > > >> > > > > > >
> >> > > > > > > > >> > > > > >
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > > > --
> >> > > > > > > > >> > > > > Sergey Kozlov
> >> > > > > > > > >> > > > > GridGain Systems
> >> > > > > > > > >> > > > > www.gridgain.com
> >> > > > > > > > >> > > > >
> >> > > > > > > > >> > > >
> >> > > > > > > > >> > >
> >> > > > > > > > >> >
> >> > > > > > > > >> >
> >> > > > > > > > >> > --
> >> > > > > > > > >> > Sergey Kozlov
> >> > > > > > > > >> > GridGain Systems
> >> > > > > > > > >> > www.gridgain.com
> >> > > > > > > > >> >
> >> > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
>

[Alexey Plekhanov]

Vladimir,

Ok, then I will rewrite IEP in the near future.

чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <[hidden email]>:

> Hi Alex,
>
> I think we should be able to handle many transactions through a single
> connection. This will make our protocol and client implementations much
> more efficient, and simplicity from developer's perspective is not our
> goal. Consider normal nodes. We have server nodes and client nodes. You may
> span whatever number of transactions you need, but all of them are
> coordinated through a single connection. The same should be applicable to
> thin clients. Protocol is already designed to handle this, as we pass
> unique operation ID in order to distinguish one operation from another. It
> is true, though, that we will have to introduce a kind of "session"
> concept, and pass additional identifier along with cache operations, but
> this doesn't sound like a problem to me.
>
> And provided that currently server-side transactions are bound to threads
> artificially, I would say that the first step in implementation of
> transactions on thin clients should be decoupling server-side transactions
> from threads. Without this we will have very inefficient implementation,
> when every new client transaction have to spawn a new thread. This is slow
> and introduces high memory pressure on a cluster node. We already work this
> way for MVCC transactions which are spawned from JDBC driver, and believe
> me, we do not want to replicated this bad practice to other clients :-)
>
> Vladimir.
>
> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <[hidden email]>
> wrote:
>
> > Guys, so, do we need multiple concurrent transactions per connection?
> >
> > There are pros and cons for each approach. Difference between approaches:
> >
> > One transaction at a time per connection:
> >  - This approach is used in RDBMS world and users got used to it
> >  - To use transactions concurrently users need to use different
> connections
> > and get these connections via something like a connection pool
> >  - Easy to implement (in fact, PoC is already done)
> >
> > Multiple concurrent transactions per connection:
> >  - At least for java thin client, we can implement transaction per thread
> > approach as implemented now for the thick client (perhaps other thin
> > clients can implement the same abstraction)
> >  - There is also protocol change for all cache operations needed (to bind
> > cache operation to the transaction)
> >  - Significant changes to all implemented clients are needed
> >  - Implementation on the server side is more complex
> >
> > What do you think?
> >
> >
> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <[hidden email]>:
> >
> > > Ilya,
> > >
> > > > We should be able to multiplex several transactions using a single
> > > Client connection.
> > > In this case, we should significantly change cache operations syntax
> (for
> > > each implemented client), to bind each operation to the transaction.
> > >
> > > > I want to also ask if "Number of entries participating in transaction
> > > (may be approximate). 0 - default value." is needed.
> > > I've tried to minimize API changes between thick and thin client to
> > > simplify move from one to another. It's the only reason. But I agree
> with
> > > you, the parameter is not very useful.
> > >
> > >
> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <[hidden email]
> >:
> > >
> > >> Hello!
> > >>
> > >> Pavel, I agree with you thorougly. We should be able to multiplex
> > several
> > >> transactions using a single Client connection. This means adding
> > >> Transaction id parameter to every affected cache operation / SQL
> > statement
> > >> (if applicable) to make sure we do cache operations on relevant
> > >> transaction.
> > >>
> > >> This is how other things work in Ignite, such as communication. We do
> > not
> > >> open dozens of connections, we multiplex operations asynchronously
> > through
> > >> a single connection.
> > >>
> > >> I think that trying to pool Ignite connections will be highly
> > >> inconvenient,
> > >> since there is no existing infrastructure for such pooling (like there
> > >> exists for JDBC).
> > >>
> > >> I want to also ask if "Number of entries participating in transaction
> > (may
> > >> be approximate). 0 - default value." is needed. Does it actually do
> > >> anything in our tx protocol? Users of existing APIs are already
> confused
> > >> by
> > >> this parameter, if we could get rid of it in thin client protocol it
> > would
> > >> be nice clean-up.
> > >>
> > >> Regards,
> > >> --
> > >> Ilya Kasnacheev
> > >>
> > >>
> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]>:
> > >>
> > >> > Alex,
> > >> >
> > >> > > now we can only support one active transaction per connection
> > >> >
> > >> > I totally understand server-side and protocol limitations that are
> > >> causing
> > >> > this.
> > >> > But I have no idea how to support this in .NET Thin Client, for
> > example.
> > >> >
> > >> > It is thread-safe and can handle multiple async operations in
> > parallel.
> > >> > But with TX support we have to somehow switch to single-threaded
> mode
> > to
> > >> > avoid unexpected effects.
> > >> >
> > >> > Any ideas?
> > >> >
> > >> >
> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <
> [hidden email]
> > >
> > >> > wrote:
> > >> >
> > >> > > Dmitriy, thank you!
> > >> > >
> > >> > > Guys, I've created the IEP [1] on wiki, please have a look.
> > >> > >
> > >> > > [1]
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >> > >
> > >> > >
> > >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <[hidden email]>:
> > >> > >
> > >> > > > Hi,
> > >> > > >
> > >> > > > I've added permissions to account plehanov.alex
> > >> > > >
> > >> > > > Recently Infra integrated Apache LDAP with confluence, so it is
> > >> > possible
> > >> > > to
> > >> > > > login using Apache credentials. Probably we can ask infra if
> extra
> > >> > > > permissions to edit pages should be added for committers.
> > >> > > >
> > >> > > > Sincerely,
> > >> > > > Dmitriy Pavlov
> > >> > > >
> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
> > [hidden email]
> > >> >:
> > >> > > >
> > >> > > > > Vladimir,
> > >> > > > >
> > >> > > > > About current tx: ok, then we don't need tx() method in the
> > >> interface
> > >> > > at
> > >> > > > > all (the same cached transaction info user can store by
> > himself).
> > >> > > > >
> > >> > > > > About decoupling transactions from threads on the server side:
> > for
> > >> > now,
> > >> > > > we
> > >> > > > > can start with thread-per-connection approach (we only can
> > support
> > >> > one
> > >> > > > > active transaction per connection, see below, so we need one
> > >> > additional
> > >> > > > > dedicated thread for each connection with active transaction),
> > and
> > >> > > later
> > >> > > > > change server-side internals to process client transactions in
> > any
> > >> > > server
> > >> > > > > thread (not dedicated to this connection). This change will
> not
> > >> > affect
> > >> > > > the
> > >> > > > > thin client protocol, it only affects the server side.
> > >> > > > > In any case, we can't support concurrent transactions per
> > >> connection
> > >> > on
> > >> > > > > the client side without fundamental changes to the current
> > >> protocol
> > >> > > > (cache
> > >> > > > > operation doesn't bound to transaction or thread and the
> server
> > >> > doesn't
> > >> > > > > know which thread on the client side do this cache operation).
> > In
> > >> my
> > >> > > > > opinion, if a user wants to use concurrent transactions, he
> must
> > >> use
> > >> > > > > different connections from a connection pool.
> > >> > > > >
> > >> > > > > About semantics of suspend/resume on the client-side: it's
> > >> absolutely
> > >> > > > > different than server-side semantics (we don't need to do
> > >> > > suspend/resume
> > >> > > > to
> > >> > > > > pass transaction between threads on the client-side), but
> can't
> > be
> > >> > > > > implemented efficiently without implemented suspend/resume on
> > >> > > > server-side.
> > >> > > > >
> > >> > > > > Can anyone give me permissions to create IEP on Apache wiki?
> > >> > > > >
> > >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
> > >> [hidden email]>:
> > >> > > > >
> > >> > > > > > Hi Alex,
> > >> > > > > >
> > >> > > > > > My comments was only about the protocol. Getting current
> info
> > >> about
> > >> > > > > > transaction should be handled by the client itself. It is
> not
> > >> > > protocl's
> > >> > > > > > concern. Same about other APIs and behavior in case another
> > >> > > transaction
> > >> > > > > is
> > >> > > > > > attempted from the same thread.
> > >> > > > > >
> > >> > > > > > Putting protocol aside, transaction support is complicated
> > >> matter.
> > >> > I
> > >> > > > > would
> > >> > > > > > propose to route through IEP and wide community discussion.
> We
> > >> need
> > >> > > to
> > >> > > > > > review API and semantics very carefully, taking
> SUSPEND/RESUME
> > >> in
> > >> > > > count.
> > >> > > > > > Also I do not see how we support client transactions
> > efficiently
> > >> > > > without
> > >> > > > > > decoupling transactions from threads on the server side
> first.
> > >> > > Because
> > >> > > > > > without it you will need a dedicated server thread for every
> > >> > client's
> > >> > > > > > transaction which is slow and may even crash the server.
> > >> > > > > >
> > >> > > > > > Vladimir.
> > >> > > > > >
> > >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > >> > > > [hidden email]>
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Vladimir, what if we want to get current transaction info
> > >> (tx()
> > >> > > > > method)?
> > >> > > > > > >
> > >> > > > > > > Does close() method mapped to TX_END(rollback)?
> > >> > > > > > >
> > >> > > > > > > For example, this code:
> > >> > > > > > >
> > >> > > > > > > try(tx = txStart()) {
> > >> > > > > > >     tx.commit();
> > >> > > > > > > }
> > >> > > > > > >
> > >> > > > > > > Will produce:
> > >> > > > > > > TX_START
> > >> > > > > > > TX_END(commit)
> > >> > > > > > > TX_END(rollback)
> > >> > > > > > >
> > >> > > > > > > Am I understand you right?
> > >> > > > > > >
> > >> > > > > > > About xid. There is yet another proposal. Use some unique
> > per
> > >> > > > > connection
> > >> > > > > > id
> > >> > > > > > > (integer, simple counter) for identifying the transaction
> on
> > >> > > > > > > commit/rollback message. The client gets this id from the
> > >> server
> > >> > > with
> > >> > > > > > > transaction info and sends it back to the server when
> trying
> > >> to
> > >> > > > > > > commit/rollback transaction. This id is not shown to
> users.
> > >> But
> > >> > > also
> > >> > > > we
> > >> > > > > > can
> > >> > > > > > > pass from server to client real transaction id (xid) with
> > >> > > transaction
> > >> > > > > > info
> > >> > > > > > > for diagnostic purposes.
> > >> > > > > > >
> > >> > > > > > > And one more question: what should we do if the client
> > starts
> > >> a
> > >> > new
> > >> > > > > > > transaction without ending the old one? Should we end the
> > old
> > >> > > > > transaction
> > >> > > > > > > implicitly (rollback) or throw an exception to the client?
> > In
> > >> my
> > >> > > > > opinion,
> > >> > > > > > > the first option is better. For example, if we got a
> > >> previously
> > >> > > used
> > >> > > > > > > connection from the connection pool, we should not worry
> > about
> > >> > any
> > >> > > > > > > uncompleted transaction started by the previous user of
> this
> > >> > > > > connection.
> > >> > > > > > >
> > >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> > >> > [hidden email]
> > >> > > >:
> > >> > > > > > >
> > >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support
> > them
> > >> > yet,
> > >> > > > and
> > >> > > > > > > adding
> > >> > > > > > > > them in future should not conflict with simple START/END
> > >> > > > > > infrastructure.
> > >> > > > > > > >
> > >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> > >> > > > > [hidden email]
> > >> > > > > > >
> > >> > > > > > > > wrote:
> > >> > > > > > > >
> > >> > > > > > > > > Hi Alex,
> > >> > > > > > > > >
> > >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be
> enough
> > to
> > >> > have
> > >> > > > > only
> > >> > > > > > > two?
> > >> > > > > > > > >
> > >> > > > > > > > > START - accepts optional parameters, returns
> transaction
> > >> info
> > >> > > > > > > > > END - provides commit flag, returns void
> > >> > > > > > > > >
> > >> > > > > > > > > Vladimir.
> > >> > > > > > > > >
> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> > >> > > > > > [hidden email]
> > >> > > > > > > >
> > >> > > > > > > > > wrote:
> > >> > > > > > > > >
> > >> > > > > > > > >> Sergey, yes, the close is something like silent
> > rollback.
> > >> > But
> > >> > > we
> > >> > > > > can
> > >> > > > > > > > >> also implement this on the client side, just using
> > >> rollback
> > >> > > and
> > >> > > > > > > ignoring
> > >> > > > > > > > >> errors in the response.
> > >> > > > > > > > >>
> > >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> > >> > > > [hidden email]
> > >> > > > > >:
> > >> > > > > > > > >>
> > >> > > > > > > > >> > Nikolay
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > Am I correctly understand you points:
> > >> > > > > > > > >> >
> > >> > > > > > > > >> >    - close: rollback
> > >> > > > > > > > >> >    - commit, close: do nothing
> > >> > > > > > > > >> >    - rollback, close: do what? (I suppose nothing)
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > Also you assume that after commit/rollback we may
> > need
> > >> to
> > >> > > free
> > >> > > > > > some
> > >> > > > > > > > >> > resources on server node(s)or just do on client
> > started
> > >> > TX?
> > >> > > > > > > > >> >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
> > >> > > > > > > > [hidden email]
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > wrote:
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > > Sergey, we have the close() method in the thick
> > >> client,
> > >> > > it's
> > >> > > > > > > > behavior
> > >> > > > > > > > >> is
> > >> > > > > > > > >> > > slightly different than rollback() method (it
> > should
> > >> > > > rollback
> > >> > > > > if
> > >> > > > > > > the
> > >> > > > > > > > >> > > transaction is not committed and do nothing if
> the
> > >> > > > transaction
> > >> > > > > > is
> > >> > > > > > > > >> already
> > >> > > > > > > > >> > > committed). I think we should support
> > >> try-with-resource
> > >> > > > > > semantics
> > >> > > > > > > in
> > >> > > > > > > > >> the
> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here.
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
> > >> pessimistic
> > >> > > > > > > > transactions.
> > >> > > > > > > > >> > Also,
> > >> > > > > > > > >> > > the main goal of suspend/resume operations is to
> > >> support
> > >> > > > > > > transaction
> > >> > > > > > > > >> > > passing between threads. In the thin client, the
> > >> > > transaction
> > >> > > > > is
> > >> > > > > > > > bound
> > >> > > > > > > > >> to
> > >> > > > > > > > >> > > the client connection, not client thread. I think
> > >> > passing
> > >> > > a
> > >> > > > > > > > >> transaction
> > >> > > > > > > > >> > > between different client connections is not a
> very
> > >> > useful
> > >> > > > > case.
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov <
> > >> > > > > > [hidden email]
> > >> > > > > > > >:
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > We also have suspend and resume operations.
> > >> > > > > > > > >> > > > I think we should support them
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> > >> > > > > > [hidden email]
> > >> > > > > > > >:
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > > Hi
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > Looks like I missed something but why we need
> > >> > > > OP_TX_CLOSE
> > >> > > > > > > > >> operation?
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > Also I suggest to reserve a code for
> SAVEPOINT
> > >> > > operation
> > >> > > > > > which
> > >> > > > > > > > >> very
> > >> > > > > > > > >> > > > useful
> > >> > > > > > > > >> > > > > to understand where transaction has been
> rolled
> > >> back
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex
> Plehanov <
> > >> > > > > > > > >> > [hidden email]
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > > > > wrote:
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > > Hello Igniters!
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369
> and
> > >> add
> > >> > > > > > > transactions
> > >> > > > > > > > >> > support
> > >> > > > > > > > >> > > > to
> > >> > > > > > > > >> > > > > > our thin client implementation.
> > >> > > > > > > > >> > > > > > I've looked at our current implementation
> and
> > >> have
> > >> > > > some
> > >> > > > > > > > >> proposals
> > >> > > > > > > > >> > to
> > >> > > > > > > > >> > > > > > support transactions:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > Add new operations to thin client protocol:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current
> transaction
> > >> for
> > >> > > > client
> > >> > > > > > > > >> connection
> > >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
> > transaction
> > >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit transaction
> > >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
> > transaction
> > >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close transaction
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > From the client side (java) new interfaces
> > >> will be
> > >> > > > > added:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > public interface ClientTransactions {
> > >> > > > > > > > >> > > > > >     public ClientTransaction txStart();
> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > >> > > > > > txStart(TransactionConcurrency
> > >> > > > > > > > >> > > > concurrency,
> > >> > > > > > > > >> > > > > > TransactionIsolation isolation);
> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > >> > > > > > txStart(TransactionConcurrency
> > >> > > > > > > > >> > > > concurrency,
> > >> > > > > > > > >> > > > > > TransactionIsolation isolation, long
> timeout,
> > >> int
> > >> > > > > txSize);
> > >> > > > > > > > >> > > > > >     public ClientTransaction tx(); // Get
> > >> current
> > >> > > > > > connection
> > >> > > > > > > > >> > > > transaction
> > >> > > > > > > > >> > > > > >     public ClientTransactions
> > withLabel(String
> > >> > lb);
> > >> > > > > > > > >> > > > > > }
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > public interface ClientTransaction extends
> > >> > > > > AutoCloseable {
> > >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we need
> > it?
> > >> > > > > > > > >> > > > > >     public TransactionIsolation
> isolation();
> > >> > > > > > > > >> > > > > >     public TransactionConcurrency
> > >> concurrency();
> > >> > > > > > > > >> > > > > >     public long timeout();
> > >> > > > > > > > >> > > > > >     public String label();
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > >     public void commit();
> > >> > > > > > > > >> > > > > >     public void rollback();
> > >> > > > > > > > >> > > > > >     public void close();
> > >> > > > > > > > >> > > > > > }
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > From the server side, I think as a first
> step
> > >> > (while
> > >> > > > > > > > >> transactions
> > >> > > > > > > > >> > > > > > suspend/resume is not fully implemented) we
> > can
> > >> > use
> > >> > > > the
> > >> > > > > > same
> > >> > > > > > > > >> > approach
> > >> > > > > > > > >> > > > as
> > >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> > >> > > > ClientRequestHandler
> > >> > > > > > and
> > >> > > > > > > > >> process
> > >> > > > > > > > >> > > > > > requests by this worker if the transaction
> is
> > >> > > started
> > >> > > > > > > > >> explicitly.
> > >> > > > > > > > >> > > > > > ClientRequestHandler is bound to client
> > >> > connection,
> > >> > > so
> > >> > > > > > there
> > >> > > > > > > > >> will
> > >> > > > > > > > >> > be
> > >> > > > > > > > >> > > > 1:1
> > >> > > > > > > > >> > > > > > relation between client connection and
> > thread,
> > >> > which
> > >> > > > > > process
> > >> > > > > > > > >> > > operations
> > >> > > > > > > > >> > > > > in
> > >> > > > > > > > >> > > > > > a transaction.
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > Also, there is a couple of issues I want to
> > >> > discuss:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > We have overloaded method txStart with a
> > >> different
> > >> > > set
> > >> > > > > of
> > >> > > > > > > > >> > arguments.
> > >> > > > > > > > >> > > > Some
> > >> > > > > > > > >> > > > > > of the arguments may be missing. To pass
> > >> arguments
> > >> > > > with
> > >> > > > > > > > >> OP_TX_START
> > >> > > > > > > > >> > > > > > operation we have the next options:
> > >> > > > > > > > >> > > > > >  * Serialize full set of arguments and use
> > some
> > >> > > value
> > >> > > > > for
> > >> > > > > > > > >> missing
> > >> > > > > > > > >> > > > > > arguments. For example -1 for int/long
> types
> > >> and
> > >> > > null
> > >> > > > > for
> > >> > > > > > > > string
> > >> > > > > > > > >> > > type.
> > >> > > > > > > > >> > > > We
> > >> > > > > > > > >> > > > > > can't use 0 for int/long types since 0
> it's a
> > >> > valid
> > >> > > > > value
> > >> > > > > > > for
> > >> > > > > > > > >> > > > > concurrency,
> > >> > > > > > > > >> > > > > > isolation and timeout arguments.
> > >> > > > > > > > >> > > > > >  * Serialize arguments as a collection of
> > >> > > > property-value
> > >> > > > > > > pairs
> > >> > > > > > > > >> > (like
> > >> > > > > > > > >> > > > it's
> > >> > > > > > > > >> > > > > > implemented now for CacheConfiguration). In
> > >> this
> > >> > > case
> > >> > > > > only
> > >> > > > > > > > >> > explicitly
> > >> > > > > > > > >> > > > > > provided arguments will be serialized.
> > >> > > > > > > > >> > > > > > Which way is better? The simplest solution
> is
> > >> to
> > >> > use
> > >> > > > the
> > >> > > > > > > first
> > >> > > > > > > > >> > option
> > >> > > > > > > > >> > > > > and I
> > >> > > > > > > > >> > > > > > want to use it if there were no objections.
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > Do we need transaction id (xid) on the
> client
> > >> > side?
> > >> > > > > > > > >> > > > > > If yes, we can pass xid along with
> > >> OP_TX_COMMIT,
> > >> > > > > > > > OP_TX_ROLLBACK,
> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server
> and
> > >> do
> > >> > > > > > additional
> > >> > > > > > > > >> check
> > >> > > > > > > > >> > on
> > >> > > > > > > > >> > > > the
> > >> > > > > > > > >> > > > > > server side (current transaction id for
> > >> connection
> > >> > > ==
> > >> > > > > > > > >> transaction
> > >> > > > > > > > >> > id
> > >> > > > > > > > >> > > > > passed
> > >> > > > > > > > >> > > > > > from client side). This, perhaps, will
> > protect
> > >> > > clients
> > >> > > > > > > against
> > >> > > > > > > > >> some
> > >> > > > > > > > >> > > > > errors
> > >> > > > > > > > >> > > > > > (for example when client try to commit
> > outdated
> > >> > > > > > > transaction).
> > >> > > > > > > > >> But
> > >> > > > > > > > >> > > > > > currently, we don't have data type
> IgniteUuid
> > >> in
> > >> > > thin
> > >> > > > > > client
> > >> > > > > > > > >> > > protocol.
> > >> > > > > > > > >> > > > Do
> > >> > > > > > > > >> > > > > > we need to add it too?
> > >> > > > > > > > >> > > > > > Also, we can pass xid as a string just to
> > >> inform
> > >> > the
> > >> > > > > > client
> > >> > > > > > > > and
> > >> > > > > > > > >> do
> > >> > > > > > > > >> > > not
> > >> > > > > > > > >> > > > > pass
> > >> > > > > > > > >> > > > > > it back to the server with commit/rollback
> > >> > > operation.
> > >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick
> client
> > >> works
> > >> > > > this
> > >> > > > > > way
> > >> > > > > > > as
> > >> > > > > > > > >> far
> > >> > > > > > > > >> > > as I
> > >> > > > > > > > >> > > > > > know).
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > What do you think?
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir
> Ozerov <
> > >> > > > > > > > >> [hidden email]
> > >> > > > > > > > >> > >:
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > > > > We already have transactions support in
> > JDBC
> > >> > > driver
> > >> > > > in
> > >> > > > > > TX
> > >> > > > > > > > SQL
> > >> > > > > > > > >> > > branch
> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is
> implemented
> > >> > through
> > >> > > > > > > separate
> > >> > > > > > > > >> > thread,
> > >> > > > > > > > >> > > > > which
> > >> > > > > > > > >> > > > > > > is not that efficient. Ideally we need to
> > >> finish
> > >> > > > > > > decoupling
> > >> > > > > > > > >> > > > > transactions
> > >> > > > > > > > >> > > > > > > from threads. But alternatively we can
> > change
> > >> > the
> > >> > > > > logic
> > >> > > > > > on
> > >> > > > > > > > >> how we
> > >> > > > > > > > >> > > > > assign
> > >> > > > > > > > >> > > > > > > thread ID to specific transaction and
> > >> > > "impersonate"
> > >> > > > > thin
> > >> > > > > > > > >> client
> > >> > > > > > > > >> > > > worker
> > >> > > > > > > > >> > > > > > > threads when serving requests from
> multiple
> > >> > users.
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis
> > Magda
> > >> <
> > >> > > > > > > > >> [hidden email]>
> > >> > > > > > > > >> > > > > wrote:
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > > > > Here is an original discussion with a
> > >> > reference
> > >> > > to
> > >> > > > > the
> > >> > > > > > > > JIRA
> > >> > > > > > > > >> > > ticket:
> > >> > > > > > > > >> > > > > > > >
> > >> > > http://apache-ignite-developers.2346864.n4.nabble
> > >> > > > .
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > >
> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > >> > > > > > > > >> > > > > > > > Protocol-td25914.html
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > > > --
> > >> > > > > > > > >> > > > > > > > Denis
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM, Dmitriy
> > >> > > Setrakyan
> > >> > > > <
> > >> > > > > > > > >> > > > > > [hidden email]
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > > > wrote:
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a
> > >> design
> > >> > > > > proposal
> > >> > > > > > > for
> > >> > > > > > > > >> > > > transaction
> > >> > > > > > > > >> > > > > > > > support
> > >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking
> > this
> > >> > > > > initiative
> > >> > > > > > > and
> > >> > > > > > > > >> > > creating
> > >> > > > > > > > >> > > > an
> > >> > > > > > > > >> > > > > > IEP
> > >> > > > > > > > >> > > > > > > > on
> > >> > > > > > > > >> > > > > > > > > Wiki?
> > >> > > > > > > > >> > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > D.
> > >> > > > > > > > >> > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM,
> Dmitriy
> > >> > > > > Govorukhin <
> > >> > > > > > > > >> > > > > > > > > [hidden email]> wrote:
> > >> > > > > > > > >> > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> > >> > > > > > > > >> > > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions
> about
> > >> thin
> > >> > > > client
> > >> > > > > > and
> > >> > > > > > > > >> binary
> > >> > > > > > > > >> > > > > > protocol,
> > >> > > > > > > > >> > > > > > > > > but I
> > >> > > > > > > > >> > > > > > > > > > did not hear anything about
> > >> transactions
> > >> > > > > support.
> > >> > > > > > Do
> > >> > > > > > > > we
> > >> > > > > > > > >> > have
> > >> > > > > > > > >> > > > some
> > >> > > > > > > > >> > > > > > > draft
> > >> > > > > > > > >> > > > > > > > > for
> > >> > > > > > > > >> > > > > > > > > > this purpose?
> > >> > > > > > > > >> > > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > > As I understand we have several
> > >> problems:
> > >> > > > > > > > >> > > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > >    - thread and transaction have
> hard
> > >> > > related
> > >> > > > > (we
> > >> > > > > > > use
> > >> > > > > > > > >> > > > > thread-local
> > >> > > > > > > > >> > > > > > > > > variable
> > >> > > > > > > > >> > > > > > > > > >    and thread name)
> > >> > > > > > > > >> > > > > > > > > >    - we can process only one
> > >> transaction
> > >> > at
> > >> > > > the
> > >> > > > > > same
> > >> > > > > > > > >> time
> > >> > > > > > > > >> > in
> > >> > > > > > > > >> > > > one
> > >> > > > > > > > >> > > > > > > thread
> > >> > > > > > > > >> > > > > > > > > (it
> > >> > > > > > > > >> > > > > > > > > >    mean we need hold thread per
> > >> client. If
> > >> > > > > connect
> > >> > > > > > > 100
> > >> > > > > > > > >> thin
> > >> > > > > > > > >> > > > > clients
> > >> > > > > > > > >> > > > > > > to
> > >> > > > > > > > >> > > > > > > > 1
> > >> > > > > > > > >> > > > > > > > > >    server node, then need to hold
> 100
> > >> > thread
> > >> > > > on
> > >> > > > > > the
> > >> > > > > > > > >> server
> > >> > > > > > > > >> > > > side)
> > >> > > > > > > > >> > > > > > > > > >
> > >> > > > > > > > >> > > > > > > > > > Let's discuss how we can implement
> > >> > > > transactions
> > >> > > > > > for
> > >> > > > > > > > the
> > >> > > > > > > > >> > thin
> > >> > > > > > > > >> > > > > > client.
> > >> > > > > > > > >> > > > > > > > > >
> > >> > > > > > > > >> > > > > > > > >
> > >> > > > > > > > >> > > > > > > >
> > >> > > > > > > > >> > > > > > >
> > >> > > > > > > > >> > > > > >
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > > > --
> > >> > > > > > > > >> > > > > Sergey Kozlov
> > >> > > > > > > > >> > > > > GridGain Systems
> > >> > > > > > > > >> > > > > www.gridgain.com
> > >> > > > > > > > >> > > > >
> > >> > > > > > > > >> > > >
> > >> > > > > > > > >> > >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> >
> > >> > > > > > > > >> > --
> > >> > > > > > > > >> > Sergey Kozlov
> > >> > > > > > > > >> > GridGain Systems
> > >> > > > > > > > >> > www.gridgain.com
> > >> > > > > > > > >> >
> > >> > > > > > > > >>
> > >> > > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>

[Alexey Plekhanov]

Hello, Igniters!

I've update IEP [1] and implement PoC according to new approach (multiple
concurrent transactions per connection).
But to move forward another feature need to be implemented: suspend/resume
for pessimistic transactions (IGNITE-5714 [2]). Implementation of
suspend/resume is ready now and ticket in 'Patch available' status. Can any
transactions expert help with review of IGNITE-5714?

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

чт, 4 апр. 2019 г. в 11:32, Alex Plehanov <[hidden email]>:

> Vladimir,
>
> Ok, then I will rewrite IEP in the near future.
>
> чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <[hidden email]>:
>
>> Hi Alex,
>>
>> I think we should be able to handle many transactions through a single
>> connection. This will make our protocol and client implementations much
>> more efficient, and simplicity from developer's perspective is not our
>> goal. Consider normal nodes. We have server nodes and client nodes. You
>> may
>> span whatever number of transactions you need, but all of them are
>> coordinated through a single connection. The same should be applicable to
>> thin clients. Protocol is already designed to handle this, as we pass
>> unique operation ID in order to distinguish one operation from another. It
>> is true, though, that we will have to introduce a kind of "session"
>> concept, and pass additional identifier along with cache operations, but
>> this doesn't sound like a problem to me.
>>
>> And provided that currently server-side transactions are bound to threads
>> artificially, I would say that the first step in implementation of
>> transactions on thin clients should be decoupling server-side transactions
>> from threads. Without this we will have very inefficient implementation,
>> when every new client transaction have to spawn a new thread. This is slow
>> and introduces high memory pressure on a cluster node. We already work
>> this
>> way for MVCC transactions which are spawned from JDBC driver, and believe
>> me, we do not want to replicated this bad practice to other clients :-)
>>
>> Vladimir.
>>
>> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <[hidden email]>
>> wrote:
>>
>> > Guys, so, do we need multiple concurrent transactions per connection?
>> >
>> > There are pros and cons for each approach. Difference between
>> approaches:
>> >
>> > One transaction at a time per connection:
>> >  - This approach is used in RDBMS world and users got used to it
>> >  - To use transactions concurrently users need to use different
>> connections
>> > and get these connections via something like a connection pool
>> >  - Easy to implement (in fact, PoC is already done)
>> >
>> > Multiple concurrent transactions per connection:
>> >  - At least for java thin client, we can implement transaction per
>> thread
>> > approach as implemented now for the thick client (perhaps other thin
>> > clients can implement the same abstraction)
>> >  - There is also protocol change for all cache operations needed (to
>> bind
>> > cache operation to the transaction)
>> >  - Significant changes to all implemented clients are needed
>> >  - Implementation on the server side is more complex
>> >
>> > What do you think?
>> >
>> >
>> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <[hidden email]>:
>> >
>> > > Ilya,
>> > >
>> > > > We should be able to multiplex several transactions using a single
>> > > Client connection.
>> > > In this case, we should significantly change cache operations syntax
>> (for
>> > > each implemented client), to bind each operation to the transaction.
>> > >
>> > > > I want to also ask if "Number of entries participating in
>> transaction
>> > > (may be approximate). 0 - default value." is needed.
>> > > I've tried to minimize API changes between thick and thin client to
>> > > simplify move from one to another. It's the only reason. But I agree
>> with
>> > > you, the parameter is not very useful.
>> > >
>> > >
>> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <
>> [hidden email]>:
>> > >
>> > >> Hello!
>> > >>
>> > >> Pavel, I agree with you thorougly. We should be able to multiplex
>> > several
>> > >> transactions using a single Client connection. This means adding
>> > >> Transaction id parameter to every affected cache operation / SQL
>> > statement
>> > >> (if applicable) to make sure we do cache operations on relevant
>> > >> transaction.
>> > >>
>> > >> This is how other things work in Ignite, such as communication. We do
>> > not
>> > >> open dozens of connections, we multiplex operations asynchronously
>> > through
>> > >> a single connection.
>> > >>
>> > >> I think that trying to pool Ignite connections will be highly
>> > >> inconvenient,
>> > >> since there is no existing infrastructure for such pooling (like
>> there
>> > >> exists for JDBC).
>> > >>
>> > >> I want to also ask if "Number of entries participating in transaction
>> > (may
>> > >> be approximate). 0 - default value." is needed. Does it actually do
>> > >> anything in our tx protocol? Users of existing APIs are already
>> confused
>> > >> by
>> > >> this parameter, if we could get rid of it in thin client protocol it
>> > would
>> > >> be nice clean-up.
>> > >>
>> > >> Regards,
>> > >> --
>> > >> Ilya Kasnacheev
>> > >>
>> > >>
>> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]>:
>> > >>
>> > >> > Alex,
>> > >> >
>> > >> > > now we can only support one active transaction per connection
>> > >> >
>> > >> > I totally understand server-side and protocol limitations that are
>> > >> causing
>> > >> > this.
>> > >> > But I have no idea how to support this in .NET Thin Client, for
>> > example.
>> > >> >
>> > >> > It is thread-safe and can handle multiple async operations in
>> > parallel.
>> > >> > But with TX support we have to somehow switch to single-threaded
>> mode
>> > to
>> > >> > avoid unexpected effects.
>> > >> >
>> > >> > Any ideas?
>> > >> >
>> > >> >
>> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <
>> [hidden email]
>> > >
>> > >> > wrote:
>> > >> >
>> > >> > > Dmitriy, thank you!
>> > >> > >
>> > >> > > Guys, I've created the IEP [1] on wiki, please have a look.
>> > >> > >
>> > >> > > [1]
>> > >> > >
>> > >> > >
>> > >> >
>> > >>
>> >
>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>> > >> > >
>> > >> > >
>> > >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <[hidden email]
>> >:
>> > >> > >
>> > >> > > > Hi,
>> > >> > > >
>> > >> > > > I've added permissions to account plehanov.alex
>> > >> > > >
>> > >> > > > Recently Infra integrated Apache LDAP with confluence, so it is
>> > >> > possible
>> > >> > > to
>> > >> > > > login using Apache credentials. Probably we can ask infra if
>> extra
>> > >> > > > permissions to edit pages should be added for committers.
>> > >> > > >
>> > >> > > > Sincerely,
>> > >> > > > Dmitriy Pavlov
>> > >> > > >
>> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
>> > [hidden email]
>> > >> >:
>> > >> > > >
>> > >> > > > > Vladimir,
>> > >> > > > >
>> > >> > > > > About current tx: ok, then we don't need tx() method in the
>> > >> interface
>> > >> > > at
>> > >> > > > > all (the same cached transaction info user can store by
>> > himself).
>> > >> > > > >
>> > >> > > > > About decoupling transactions from threads on the server
>> side:
>> > for
>> > >> > now,
>> > >> > > > we
>> > >> > > > > can start with thread-per-connection approach (we only can
>> > support
>> > >> > one
>> > >> > > > > active transaction per connection, see below, so we need one
>> > >> > additional
>> > >> > > > > dedicated thread for each connection with active
>> transaction),
>> > and
>> > >> > > later
>> > >> > > > > change server-side internals to process client transactions
>> in
>> > any
>> > >> > > server
>> > >> > > > > thread (not dedicated to this connection). This change will
>> not
>> > >> > affect
>> > >> > > > the
>> > >> > > > > thin client protocol, it only affects the server side.
>> > >> > > > > In any case, we can't support concurrent transactions per
>> > >> connection
>> > >> > on
>> > >> > > > > the client side without fundamental changes to the current
>> > >> protocol
>> > >> > > > (cache
>> > >> > > > > operation doesn't bound to transaction or thread and the
>> server
>> > >> > doesn't
>> > >> > > > > know which thread on the client side do this cache
>> operation).
>> > In
>> > >> my
>> > >> > > > > opinion, if a user wants to use concurrent transactions, he
>> must
>> > >> use
>> > >> > > > > different connections from a connection pool.
>> > >> > > > >
>> > >> > > > > About semantics of suspend/resume on the client-side: it's
>> > >> absolutely
>> > >> > > > > different than server-side semantics (we don't need to do
>> > >> > > suspend/resume
>> > >> > > > to
>> > >> > > > > pass transaction between threads on the client-side), but
>> can't
>> > be
>> > >> > > > > implemented efficiently without implemented suspend/resume on
>> > >> > > > server-side.
>> > >> > > > >
>> > >> > > > > Can anyone give me permissions to create IEP on Apache wiki?
>> > >> > > > >
>> > >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
>> > >> [hidden email]>:
>> > >> > > > >
>> > >> > > > > > Hi Alex,
>> > >> > > > > >
>> > >> > > > > > My comments was only about the protocol. Getting current
>> info
>> > >> about
>> > >> > > > > > transaction should be handled by the client itself. It is
>> not
>> > >> > > protocl's
>> > >> > > > > > concern. Same about other APIs and behavior in case another
>> > >> > > transaction
>> > >> > > > > is
>> > >> > > > > > attempted from the same thread.
>> > >> > > > > >
>> > >> > > > > > Putting protocol aside, transaction support is complicated
>> > >> matter.
>> > >> > I
>> > >> > > > > would
>> > >> > > > > > propose to route through IEP and wide community
>> discussion. We
>> > >> need
>> > >> > > to
>> > >> > > > > > review API and semantics very carefully, taking
>> SUSPEND/RESUME
>> > >> in
>> > >> > > > count.
>> > >> > > > > > Also I do not see how we support client transactions
>> > efficiently
>> > >> > > > without
>> > >> > > > > > decoupling transactions from threads on the server side
>> first.
>> > >> > > Because
>> > >> > > > > > without it you will need a dedicated server thread for
>> every
>> > >> > client's
>> > >> > > > > > transaction which is slow and may even crash the server.
>> > >> > > > > >
>> > >> > > > > > Vladimir.
>> > >> > > > > >
>> > >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
>> > >> > > > [hidden email]>
>> > >> > > > > > wrote:
>> > >> > > > > >
>> > >> > > > > > > Vladimir, what if we want to get current transaction info
>> > >> (tx()
>> > >> > > > > method)?
>> > >> > > > > > >
>> > >> > > > > > > Does close() method mapped to TX_END(rollback)?
>> > >> > > > > > >
>> > >> > > > > > > For example, this code:
>> > >> > > > > > >
>> > >> > > > > > > try(tx = txStart()) {
>> > >> > > > > > >     tx.commit();
>> > >> > > > > > > }
>> > >> > > > > > >
>> > >> > > > > > > Will produce:
>> > >> > > > > > > TX_START
>> > >> > > > > > > TX_END(commit)
>> > >> > > > > > > TX_END(rollback)
>> > >> > > > > > >
>> > >> > > > > > > Am I understand you right?
>> > >> > > > > > >
>> > >> > > > > > > About xid. There is yet another proposal. Use some unique
>> > per
>> > >> > > > > connection
>> > >> > > > > > id
>> > >> > > > > > > (integer, simple counter) for identifying the
>> transaction on
>> > >> > > > > > > commit/rollback message. The client gets this id from the
>> > >> server
>> > >> > > with
>> > >> > > > > > > transaction info and sends it back to the server when
>> trying
>> > >> to
>> > >> > > > > > > commit/rollback transaction. This id is not shown to
>> users.
>> > >> But
>> > >> > > also
>> > >> > > > we
>> > >> > > > > > can
>> > >> > > > > > > pass from server to client real transaction id (xid) with
>> > >> > > transaction
>> > >> > > > > > info
>> > >> > > > > > > for diagnostic purposes.
>> > >> > > > > > >
>> > >> > > > > > > And one more question: what should we do if the client
>> > starts
>> > >> a
>> > >> > new
>> > >> > > > > > > transaction without ending the old one? Should we end the
>> > old
>> > >> > > > > transaction
>> > >> > > > > > > implicitly (rollback) or throw an exception to the
>> client?
>> > In
>> > >> my
>> > >> > > > > opinion,
>> > >> > > > > > > the first option is better. For example, if we got a
>> > >> previously
>> > >> > > used
>> > >> > > > > > > connection from the connection pool, we should not worry
>> > about
>> > >> > any
>> > >> > > > > > > uncompleted transaction started by the previous user of
>> this
>> > >> > > > > connection.
>> > >> > > > > > >
>> > >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
>> > >> > [hidden email]
>> > >> > > >:
>> > >> > > > > > >
>> > >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support
>> > them
>> > >> > yet,
>> > >> > > > and
>> > >> > > > > > > adding
>> > >> > > > > > > > them in future should not conflict with simple
>> START/END
>> > >> > > > > > infrastructure.
>> > >> > > > > > > >
>> > >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
>> > >> > > > > [hidden email]
>> > >> > > > > > >
>> > >> > > > > > > > wrote:
>> > >> > > > > > > >
>> > >> > > > > > > > > Hi Alex,
>> > >> > > > > > > > >
>> > >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be
>> enough
>> > to
>> > >> > have
>> > >> > > > > only
>> > >> > > > > > > two?
>> > >> > > > > > > > >
>> > >> > > > > > > > > START - accepts optional parameters, returns
>> transaction
>> > >> info
>> > >> > > > > > > > > END - provides commit flag, returns void
>> > >> > > > > > > > >
>> > >> > > > > > > > > Vladimir.
>> > >> > > > > > > > >
>> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
>> > >> > > > > > [hidden email]
>> > >> > > > > > > >
>> > >> > > > > > > > > wrote:
>> > >> > > > > > > > >
>> > >> > > > > > > > >> Sergey, yes, the close is something like silent
>> > rollback.
>> > >> > But
>> > >> > > we
>> > >> > > > > can
>> > >> > > > > > > > >> also implement this on the client side, just using
>> > >> rollback
>> > >> > > and
>> > >> > > > > > > ignoring
>> > >> > > > > > > > >> errors in the response.
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
>> > >> > > > [hidden email]
>> > >> > > > > >:
>> > >> > > > > > > > >>
>> > >> > > > > > > > >> > Nikolay
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > Am I correctly understand you points:
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> >    - close: rollback
>> > >> > > > > > > > >> >    - commit, close: do nothing
>> > >> > > > > > > > >> >    - rollback, close: do what? (I suppose nothing)
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > Also you assume that after commit/rollback we may
>> > need
>> > >> to
>> > >> > > free
>> > >> > > > > > some
>> > >> > > > > > > > >> > resources on server node(s)or just do on client
>> > started
>> > >> > TX?
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
>> > >> > > > > > > > [hidden email]
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > wrote:
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > > Sergey, we have the close() method in the thick
>> > >> client,
>> > >> > > it's
>> > >> > > > > > > > behavior
>> > >> > > > > > > > >> is
>> > >> > > > > > > > >> > > slightly different than rollback() method (it
>> > should
>> > >> > > > rollback
>> > >> > > > > if
>> > >> > > > > > > the
>> > >> > > > > > > > >> > > transaction is not committed and do nothing if
>> the
>> > >> > > > transaction
>> > >> > > > > > is
>> > >> > > > > > > > >> already
>> > >> > > > > > > > >> > > committed). I think we should support
>> > >> try-with-resource
>> > >> > > > > > semantics
>> > >> > > > > > > in
>> > >> > > > > > > > >> the
>> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here.
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
>> > >> pessimistic
>> > >> > > > > > > > transactions.
>> > >> > > > > > > > >> > Also,
>> > >> > > > > > > > >> > > the main goal of suspend/resume operations is to
>> > >> support
>> > >> > > > > > > transaction
>> > >> > > > > > > > >> > > passing between threads. In the thin client, the
>> > >> > > transaction
>> > >> > > > > is
>> > >> > > > > > > > bound
>> > >> > > > > > > > >> to
>> > >> > > > > > > > >> > > the client connection, not client thread. I
>> think
>> > >> > passing
>> > >> > > a
>> > >> > > > > > > > >> transaction
>> > >> > > > > > > > >> > > between different client connections is not a
>> very
>> > >> > useful
>> > >> > > > > case.
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov <
>> > >> > > > > > [hidden email]
>> > >> > > > > > > >:
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> > > > Hello, Alex.
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > We also have suspend and resume operations.
>> > >> > > > > > > > >> > > > I think we should support them
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
>> > >> > > > > > [hidden email]
>> > >> > > > > > > >:
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > > Hi
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > > Looks like I missed something but why we
>> need
>> > >> > > > OP_TX_CLOSE
>> > >> > > > > > > > >> operation?
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > > Also I suggest to reserve a code for
>> SAVEPOINT
>> > >> > > operation
>> > >> > > > > > which
>> > >> > > > > > > > >> very
>> > >> > > > > > > > >> > > > useful
>> > >> > > > > > > > >> > > > > to understand where transaction has been
>> rolled
>> > >> back
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex
>> Plehanov <
>> > >> > > > > > > > >> > [hidden email]
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > > > > wrote:
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > > > Hello Igniters!
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369
>> and
>> > >> add
>> > >> > > > > > > transactions
>> > >> > > > > > > > >> > support
>> > >> > > > > > > > >> > > > to
>> > >> > > > > > > > >> > > > > > our thin client implementation.
>> > >> > > > > > > > >> > > > > > I've looked at our current implementation
>> and
>> > >> have
>> > >> > > > some
>> > >> > > > > > > > >> proposals
>> > >> > > > > > > > >> > to
>> > >> > > > > > > > >> > > > > > support transactions:
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > Add new operations to thin client
>> protocol:
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current
>> transaction
>> > >> for
>> > >> > > > client
>> > >> > > > > > > > >> connection
>> > >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
>> > transaction
>> > >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit transaction
>> > >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
>> > transaction
>> > >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close transaction
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > From the client side (java) new interfaces
>> > >> will be
>> > >> > > > > added:
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > public interface ClientTransactions {
>> > >> > > > > > > > >> > > > > >     public ClientTransaction txStart();
>> > >> > > > > > > > >> > > > > >     public ClientTransaction
>> > >> > > > > > txStart(TransactionConcurrency
>> > >> > > > > > > > >> > > > concurrency,
>> > >> > > > > > > > >> > > > > > TransactionIsolation isolation);
>> > >> > > > > > > > >> > > > > >     public ClientTransaction
>> > >> > > > > > txStart(TransactionConcurrency
>> > >> > > > > > > > >> > > > concurrency,
>> > >> > > > > > > > >> > > > > > TransactionIsolation isolation, long
>> timeout,
>> > >> int
>> > >> > > > > txSize);
>> > >> > > > > > > > >> > > > > >     public ClientTransaction tx(); // Get
>> > >> current
>> > >> > > > > > connection
>> > >> > > > > > > > >> > > > transaction
>> > >> > > > > > > > >> > > > > >     public ClientTransactions
>> > withLabel(String
>> > >> > lb);
>> > >> > > > > > > > >> > > > > > }
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > public interface ClientTransaction extends
>> > >> > > > > AutoCloseable {
>> > >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we need
>> > it?
>> > >> > > > > > > > >> > > > > >     public TransactionIsolation
>> isolation();
>> > >> > > > > > > > >> > > > > >     public TransactionConcurrency
>> > >> concurrency();
>> > >> > > > > > > > >> > > > > >     public long timeout();
>> > >> > > > > > > > >> > > > > >     public String label();
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > >     public void commit();
>> > >> > > > > > > > >> > > > > >     public void rollback();
>> > >> > > > > > > > >> > > > > >     public void close();
>> > >> > > > > > > > >> > > > > > }
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > From the server side, I think as a first
>> step
>> > >> > (while
>> > >> > > > > > > > >> transactions
>> > >> > > > > > > > >> > > > > > suspend/resume is not fully implemented)
>> we
>> > can
>> > >> > use
>> > >> > > > the
>> > >> > > > > > same
>> > >> > > > > > > > >> > approach
>> > >> > > > > > > > >> > > > as
>> > >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
>> > >> > > > ClientRequestHandler
>> > >> > > > > > and
>> > >> > > > > > > > >> process
>> > >> > > > > > > > >> > > > > > requests by this worker if the
>> transaction is
>> > >> > > started
>> > >> > > > > > > > >> explicitly.
>> > >> > > > > > > > >> > > > > > ClientRequestHandler is bound to client
>> > >> > connection,
>> > >> > > so
>> > >> > > > > > there
>> > >> > > > > > > > >> will
>> > >> > > > > > > > >> > be
>> > >> > > > > > > > >> > > > 1:1
>> > >> > > > > > > > >> > > > > > relation between client connection and
>> > thread,
>> > >> > which
>> > >> > > > > > process
>> > >> > > > > > > > >> > > operations
>> > >> > > > > > > > >> > > > > in
>> > >> > > > > > > > >> > > > > > a transaction.
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > Also, there is a couple of issues I want
>> to
>> > >> > discuss:
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > We have overloaded method txStart with a
>> > >> different
>> > >> > > set
>> > >> > > > > of
>> > >> > > > > > > > >> > arguments.
>> > >> > > > > > > > >> > > > Some
>> > >> > > > > > > > >> > > > > > of the arguments may be missing. To pass
>> > >> arguments
>> > >> > > > with
>> > >> > > > > > > > >> OP_TX_START
>> > >> > > > > > > > >> > > > > > operation we have the next options:
>> > >> > > > > > > > >> > > > > >  * Serialize full set of arguments and use
>> > some
>> > >> > > value
>> > >> > > > > for
>> > >> > > > > > > > >> missing
>> > >> > > > > > > > >> > > > > > arguments. For example -1 for int/long
>> types
>> > >> and
>> > >> > > null
>> > >> > > > > for
>> > >> > > > > > > > string
>> > >> > > > > > > > >> > > type.
>> > >> > > > > > > > >> > > > We
>> > >> > > > > > > > >> > > > > > can't use 0 for int/long types since 0
>> it's a
>> > >> > valid
>> > >> > > > > value
>> > >> > > > > > > for
>> > >> > > > > > > > >> > > > > concurrency,
>> > >> > > > > > > > >> > > > > > isolation and timeout arguments.
>> > >> > > > > > > > >> > > > > >  * Serialize arguments as a collection of
>> > >> > > > property-value
>> > >> > > > > > > pairs
>> > >> > > > > > > > >> > (like
>> > >> > > > > > > > >> > > > it's
>> > >> > > > > > > > >> > > > > > implemented now for CacheConfiguration).
>> In
>> > >> this
>> > >> > > case
>> > >> > > > > only
>> > >> > > > > > > > >> > explicitly
>> > >> > > > > > > > >> > > > > > provided arguments will be serialized.
>> > >> > > > > > > > >> > > > > > Which way is better? The simplest
>> solution is
>> > >> to
>> > >> > use
>> > >> > > > the
>> > >> > > > > > > first
>> > >> > > > > > > > >> > option
>> > >> > > > > > > > >> > > > > and I
>> > >> > > > > > > > >> > > > > > want to use it if there were no
>> objections.
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > Do we need transaction id (xid) on the
>> client
>> > >> > side?
>> > >> > > > > > > > >> > > > > > If yes, we can pass xid along with
>> > >> OP_TX_COMMIT,
>> > >> > > > > > > > OP_TX_ROLLBACK,
>> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server
>> and
>> > >> do
>> > >> > > > > > additional
>> > >> > > > > > > > >> check
>> > >> > > > > > > > >> > on
>> > >> > > > > > > > >> > > > the
>> > >> > > > > > > > >> > > > > > server side (current transaction id for
>> > >> connection
>> > >> > > ==
>> > >> > > > > > > > >> transaction
>> > >> > > > > > > > >> > id
>> > >> > > > > > > > >> > > > > passed
>> > >> > > > > > > > >> > > > > > from client side). This, perhaps, will
>> > protect
>> > >> > > clients
>> > >> > > > > > > against
>> > >> > > > > > > > >> some
>> > >> > > > > > > > >> > > > > errors
>> > >> > > > > > > > >> > > > > > (for example when client try to commit
>> > outdated
>> > >> > > > > > > transaction).
>> > >> > > > > > > > >> But
>> > >> > > > > > > > >> > > > > > currently, we don't have data type
>> IgniteUuid
>> > >> in
>> > >> > > thin
>> > >> > > > > > client
>> > >> > > > > > > > >> > > protocol.
>> > >> > > > > > > > >> > > > Do
>> > >> > > > > > > > >> > > > > > we need to add it too?
>> > >> > > > > > > > >> > > > > > Also, we can pass xid as a string just to
>> > >> inform
>> > >> > the
>> > >> > > > > > client
>> > >> > > > > > > > and
>> > >> > > > > > > > >> do
>> > >> > > > > > > > >> > > not
>> > >> > > > > > > > >> > > > > pass
>> > >> > > > > > > > >> > > > > > it back to the server with commit/rollback
>> > >> > > operation.
>> > >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick
>> client
>> > >> works
>> > >> > > > this
>> > >> > > > > > way
>> > >> > > > > > > as
>> > >> > > > > > > > >> far
>> > >> > > > > > > > >> > > as I
>> > >> > > > > > > > >> > > > > > know).
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > What do you think?
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir
>> Ozerov <
>> > >> > > > > > > > >> [hidden email]
>> > >> > > > > > > > >> > >:
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > > > > We already have transactions support in
>> > JDBC
>> > >> > > driver
>> > >> > > > in
>> > >> > > > > > TX
>> > >> > > > > > > > SQL
>> > >> > > > > > > > >> > > branch
>> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is
>> implemented
>> > >> > through
>> > >> > > > > > > separate
>> > >> > > > > > > > >> > thread,
>> > >> > > > > > > > >> > > > > which
>> > >> > > > > > > > >> > > > > > > is not that efficient. Ideally we need
>> to
>> > >> finish
>> > >> > > > > > > decoupling
>> > >> > > > > > > > >> > > > > transactions
>> > >> > > > > > > > >> > > > > > > from threads. But alternatively we can
>> > change
>> > >> > the
>> > >> > > > > logic
>> > >> > > > > > on
>> > >> > > > > > > > >> how we
>> > >> > > > > > > > >> > > > > assign
>> > >> > > > > > > > >> > > > > > > thread ID to specific transaction and
>> > >> > > "impersonate"
>> > >> > > > > thin
>> > >> > > > > > > > >> client
>> > >> > > > > > > > >> > > > worker
>> > >> > > > > > > > >> > > > > > > threads when serving requests from
>> multiple
>> > >> > users.
>> > >> > > > > > > > >> > > > > > >
>> > >> > > > > > > > >> > > > > > >
>> > >> > > > > > > > >> > > > > > >
>> > >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis
>> > Magda
>> > >> <
>> > >> > > > > > > > >> [hidden email]>
>> > >> > > > > > > > >> > > > > wrote:
>> > >> > > > > > > > >> > > > > > >
>> > >> > > > > > > > >> > > > > > > > Here is an original discussion with a
>> > >> > reference
>> > >> > > to
>> > >> > > > > the
>> > >> > > > > > > > JIRA
>> > >> > > > > > > > >> > > ticket:
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > http://apache-ignite-developers.2346864.n4.nabble
>> > >> > > > .
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > >
>> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
>> > >> > > > > > > > >> > > > > > > > Protocol-td25914.html
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > > >> > > > > > > > --
>> > >> > > > > > > > >> > > > > > > > Denis
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM,
>> Dmitriy
>> > >> > > Setrakyan
>> > >> > > > <
>> > >> > > > > > > > >> > > > > > [hidden email]
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > > >> > > > > > > > wrote:
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a
>> > >> design
>> > >> > > > > proposal
>> > >> > > > > > > for
>> > >> > > > > > > > >> > > > transaction
>> > >> > > > > > > > >> > > > > > > > support
>> > >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking
>> > this
>> > >> > > > > initiative
>> > >> > > > > > > and
>> > >> > > > > > > > >> > > creating
>> > >> > > > > > > > >> > > > an
>> > >> > > > > > > > >> > > > > > IEP
>> > >> > > > > > > > >> > > > > > > > on
>> > >> > > > > > > > >> > > > > > > > > Wiki?
>> > >> > > > > > > > >> > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > D.
>> > >> > > > > > > > >> > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM,
>> Dmitriy
>> > >> > > > > Govorukhin <
>> > >> > > > > > > > >> > > > > > > > > [hidden email]>
>> wrote:
>> > >> > > > > > > > >> > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
>> > >> > > > > > > > >> > > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions
>> about
>> > >> thin
>> > >> > > > client
>> > >> > > > > > and
>> > >> > > > > > > > >> binary
>> > >> > > > > > > > >> > > > > > protocol,
>> > >> > > > > > > > >> > > > > > > > > but I
>> > >> > > > > > > > >> > > > > > > > > > did not hear anything about
>> > >> transactions
>> > >> > > > > support.
>> > >> > > > > > Do
>> > >> > > > > > > > we
>> > >> > > > > > > > >> > have
>> > >> > > > > > > > >> > > > some
>> > >> > > > > > > > >> > > > > > > draft
>> > >> > > > > > > > >> > > > > > > > > for
>> > >> > > > > > > > >> > > > > > > > > > this purpose?
>> > >> > > > > > > > >> > > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > > As I understand we have several
>> > >> problems:
>> > >> > > > > > > > >> > > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > >    - thread and transaction have
>> hard
>> > >> > > related
>> > >> > > > > (we
>> > >> > > > > > > use
>> > >> > > > > > > > >> > > > > thread-local
>> > >> > > > > > > > >> > > > > > > > > variable
>> > >> > > > > > > > >> > > > > > > > > >    and thread name)
>> > >> > > > > > > > >> > > > > > > > > >    - we can process only one
>> > >> transaction
>> > >> > at
>> > >> > > > the
>> > >> > > > > > same
>> > >> > > > > > > > >> time
>> > >> > > > > > > > >> > in
>> > >> > > > > > > > >> > > > one
>> > >> > > > > > > > >> > > > > > > thread
>> > >> > > > > > > > >> > > > > > > > > (it
>> > >> > > > > > > > >> > > > > > > > > >    mean we need hold thread per
>> > >> client. If
>> > >> > > > > connect
>> > >> > > > > > > 100
>> > >> > > > > > > > >> thin
>> > >> > > > > > > > >> > > > > clients
>> > >> > > > > > > > >> > > > > > > to
>> > >> > > > > > > > >> > > > > > > > 1
>> > >> > > > > > > > >> > > > > > > > > >    server node, then need to hold
>> 100
>> > >> > thread
>> > >> > > > on
>> > >> > > > > > the
>> > >> > > > > > > > >> server
>> > >> > > > > > > > >> > > > side)
>> > >> > > > > > > > >> > > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > > > Let's discuss how we can implement
>> > >> > > > transactions
>> > >> > > > > > for
>> > >> > > > > > > > the
>> > >> > > > > > > > >> > thin
>> > >> > > > > > > > >> > > > > > client.
>> > >> > > > > > > > >> > > > > > > > > >
>> > >> > > > > > > > >> > > > > > > > >
>> > >> > > > > > > > >> > > > > > > >
>> > >> > > > > > > > >> > > > > > >
>> > >> > > > > > > > >> > > > > >
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > > > --
>> > >> > > > > > > > >> > > > > Sergey Kozlov
>> > >> > > > > > > > >> > > > > GridGain Systems
>> > >> > > > > > > > >> > > > > www.gridgain.com
>> > >> > > > > > > > >> > > > >
>> > >> > > > > > > > >> > > >
>> > >> > > > > > > > >> > >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >> > --
>> > >> > > > > > > > >> > Sergey Kozlov
>> > >> > > > > > > > >> > GridGain Systems
>> > >> > > > > > > > >> > www.gridgain.com
>> > >> > > > > > > > >> >
>> > >> > > > > > > > >>
>> > >> > > > > > > > >
>> > >> > > > > > > >
>> > >> > > > > > >
>> > >> > > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> >
>>
>

[Ivan Pavlukhin]

Hi Alex,

I went through IEP [1] and I have a couple of questions:
1. What is going to be used as transaction id? In a described protocol
I see an int field for it. Should not it be GridCacheVersion
corresponding to IgniteInternalTx#xidVersion?
2. OP_TX_END message assumes an empty response, but I think that
errors during tx finish are possible and should be returned in a
response.
3. In IEP it is stated that async processing of lock operations should
be introduced on a client side to enable concurrent operations from
different client threads. Do you have an idea how to achieve it?

Also, a bit about a suspend/resume trait. I tried to think about it
leaving away an existing transactions implementation in Ignite. As I
understood we are going to resume a tx before each cache operation in
the tx and resume the tx after the operation. All this to make an
executing thread available for other operations (e.g. in other txs).
From the first glance it seems like an inversed logic. A
straightforward way is to execute a cache operation within a
particular transaction defined as an explicit tx id argument (e.g.
cache.put(key, value, txid)). Can we do so?

And leaving for now thin client API. I cannot say that one proposed in
IEP is good or bad. I can only say that it ressembles current thick
client API. And perhaps it should not. I think that we should consider
similar APIs provided by other vendors and keep in mind that we have a
bunch of client implementations for different languages. I suppose
that we can return to it a little bit later. And I hope that we will
do it.

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

вт, 30 апр. 2019 г. в 13:24, Alex Plehanov <[hidden email]>:

>
> Hello, Igniters!
>
> I've update IEP [1] and implement PoC according to new approach (multiple
> concurrent transactions per connection).
> But to move forward another feature need to be implemented: suspend/resume
> for pessimistic transactions (IGNITE-5714 [2]). Implementation of
> suspend/resume is ready now and ticket in 'Patch available' status. Can any
> transactions expert help with review of IGNITE-5714?
>
> [1]:
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> [2]: https://issues.apache.org/jira/browse/IGNITE-5714
>
> чт, 4 апр. 2019 г. в 11:32, Alex Plehanov <[hidden email]>:
>
> > Vladimir,
> >
> > Ok, then I will rewrite IEP in the near future.
> >
> > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <[hidden email]>:
> >
> >> Hi Alex,
> >>
> >> I think we should be able to handle many transactions through a single
> >> connection. This will make our protocol and client implementations much
> >> more efficient, and simplicity from developer's perspective is not our
> >> goal. Consider normal nodes. We have server nodes and client nodes. You
> >> may
> >> span whatever number of transactions you need, but all of them are
> >> coordinated through a single connection. The same should be applicable to
> >> thin clients. Protocol is already designed to handle this, as we pass
> >> unique operation ID in order to distinguish one operation from another. It
> >> is true, though, that we will have to introduce a kind of "session"
> >> concept, and pass additional identifier along with cache operations, but
> >> this doesn't sound like a problem to me.
> >>
> >> And provided that currently server-side transactions are bound to threads
> >> artificially, I would say that the first step in implementation of
> >> transactions on thin clients should be decoupling server-side transactions
> >> from threads. Without this we will have very inefficient implementation,
> >> when every new client transaction have to spawn a new thread. This is slow
> >> and introduces high memory pressure on a cluster node. We already work
> >> this
> >> way for MVCC transactions which are spawned from JDBC driver, and believe
> >> me, we do not want to replicated this bad practice to other clients :-)
> >>
> >> Vladimir.
> >>
> >> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <[hidden email]>
> >> wrote:
> >>
> >> > Guys, so, do we need multiple concurrent transactions per connection?
> >> >
> >> > There are pros and cons for each approach. Difference between
> >> approaches:
> >> >
> >> > One transaction at a time per connection:
> >> >  - This approach is used in RDBMS world and users got used to it
> >> >  - To use transactions concurrently users need to use different
> >> connections
> >> > and get these connections via something like a connection pool
> >> >  - Easy to implement (in fact, PoC is already done)
> >> >
> >> > Multiple concurrent transactions per connection:
> >> >  - At least for java thin client, we can implement transaction per
> >> thread
> >> > approach as implemented now for the thick client (perhaps other thin
> >> > clients can implement the same abstraction)
> >> >  - There is also protocol change for all cache operations needed (to
> >> bind
> >> > cache operation to the transaction)
> >> >  - Significant changes to all implemented clients are needed
> >> >  - Implementation on the server side is more complex
> >> >
> >> > What do you think?
> >> >
> >> >
> >> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <[hidden email]>:
> >> >
> >> > > Ilya,
> >> > >
> >> > > > We should be able to multiplex several transactions using a single
> >> > > Client connection.
> >> > > In this case, we should significantly change cache operations syntax
> >> (for
> >> > > each implemented client), to bind each operation to the transaction.
> >> > >
> >> > > > I want to also ask if "Number of entries participating in
> >> transaction
> >> > > (may be approximate). 0 - default value." is needed.
> >> > > I've tried to minimize API changes between thick and thin client to
> >> > > simplify move from one to another. It's the only reason. But I agree
> >> with
> >> > > you, the parameter is not very useful.
> >> > >
> >> > >
> >> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <
> >> [hidden email]>:
> >> > >
> >> > >> Hello!
> >> > >>
> >> > >> Pavel, I agree with you thorougly. We should be able to multiplex
> >> > several
> >> > >> transactions using a single Client connection. This means adding
> >> > >> Transaction id parameter to every affected cache operation / SQL
> >> > statement
> >> > >> (if applicable) to make sure we do cache operations on relevant
> >> > >> transaction.
> >> > >>
> >> > >> This is how other things work in Ignite, such as communication. We do
> >> > not
> >> > >> open dozens of connections, we multiplex operations asynchronously
> >> > through
> >> > >> a single connection.
> >> > >>
> >> > >> I think that trying to pool Ignite connections will be highly
> >> > >> inconvenient,
> >> > >> since there is no existing infrastructure for such pooling (like
> >> there
> >> > >> exists for JDBC).
> >> > >>
> >> > >> I want to also ask if "Number of entries participating in transaction
> >> > (may
> >> > >> be approximate). 0 - default value." is needed. Does it actually do
> >> > >> anything in our tx protocol? Users of existing APIs are already
> >> confused
> >> > >> by
> >> > >> this parameter, if we could get rid of it in thin client protocol it
> >> > would
> >> > >> be nice clean-up.
> >> > >>
> >> > >> Regards,
> >> > >> --
> >> > >> Ilya Kasnacheev
> >> > >>
> >> > >>
> >> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]>:
> >> > >>
> >> > >> > Alex,
> >> > >> >
> >> > >> > > now we can only support one active transaction per connection
> >> > >> >
> >> > >> > I totally understand server-side and protocol limitations that are
> >> > >> causing
> >> > >> > this.
> >> > >> > But I have no idea how to support this in .NET Thin Client, for
> >> > example.
> >> > >> >
> >> > >> > It is thread-safe and can handle multiple async operations in
> >> > parallel.
> >> > >> > But with TX support we have to somehow switch to single-threaded
> >> mode
> >> > to
> >> > >> > avoid unexpected effects.
> >> > >> >
> >> > >> > Any ideas?
> >> > >> >
> >> > >> >
> >> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <
> >> [hidden email]
> >> > >
> >> > >> > wrote:
> >> > >> >
> >> > >> > > Dmitriy, thank you!
> >> > >> > >
> >> > >> > > Guys, I've created the IEP [1] on wiki, please have a look.
> >> > >> > >
> >> > >> > > [1]
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >> > >> > >
> >> > >> > >
> >> > >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <[hidden email]
> >> >:
> >> > >> > >
> >> > >> > > > Hi,
> >> > >> > > >
> >> > >> > > > I've added permissions to account plehanov.alex
> >> > >> > > >
> >> > >> > > > Recently Infra integrated Apache LDAP with confluence, so it is
> >> > >> > possible
> >> > >> > > to
> >> > >> > > > login using Apache credentials. Probably we can ask infra if
> >> extra
> >> > >> > > > permissions to edit pages should be added for committers.
> >> > >> > > >
> >> > >> > > > Sincerely,
> >> > >> > > > Dmitriy Pavlov
> >> > >> > > >
> >> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
> >> > [hidden email]
> >> > >> >:
> >> > >> > > >
> >> > >> > > > > Vladimir,
> >> > >> > > > >
> >> > >> > > > > About current tx: ok, then we don't need tx() method in the
> >> > >> interface
> >> > >> > > at
> >> > >> > > > > all (the same cached transaction info user can store by
> >> > himself).
> >> > >> > > > >
> >> > >> > > > > About decoupling transactions from threads on the server
> >> side:
> >> > for
> >> > >> > now,
> >> > >> > > > we
> >> > >> > > > > can start with thread-per-connection approach (we only can
> >> > support
> >> > >> > one
> >> > >> > > > > active transaction per connection, see below, so we need one
> >> > >> > additional
> >> > >> > > > > dedicated thread for each connection with active
> >> transaction),
> >> > and
> >> > >> > > later
> >> > >> > > > > change server-side internals to process client transactions
> >> in
> >> > any
> >> > >> > > server
> >> > >> > > > > thread (not dedicated to this connection). This change will
> >> not
> >> > >> > affect
> >> > >> > > > the
> >> > >> > > > > thin client protocol, it only affects the server side.
> >> > >> > > > > In any case, we can't support concurrent transactions per
> >> > >> connection
> >> > >> > on
> >> > >> > > > > the client side without fundamental changes to the current
> >> > >> protocol
> >> > >> > > > (cache
> >> > >> > > > > operation doesn't bound to transaction or thread and the
> >> server
> >> > >> > doesn't
> >> > >> > > > > know which thread on the client side do this cache
> >> operation).
> >> > In
> >> > >> my
> >> > >> > > > > opinion, if a user wants to use concurrent transactions, he
> >> must
> >> > >> use
> >> > >> > > > > different connections from a connection pool.
> >> > >> > > > >
> >> > >> > > > > About semantics of suspend/resume on the client-side: it's
> >> > >> absolutely
> >> > >> > > > > different than server-side semantics (we don't need to do
> >> > >> > > suspend/resume
> >> > >> > > > to
> >> > >> > > > > pass transaction between threads on the client-side), but
> >> can't
> >> > be
> >> > >> > > > > implemented efficiently without implemented suspend/resume on
> >> > >> > > > server-side.
> >> > >> > > > >
> >> > >> > > > > Can anyone give me permissions to create IEP on Apache wiki?
> >> > >> > > > >
> >> > >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
> >> > >> [hidden email]>:
> >> > >> > > > >
> >> > >> > > > > > Hi Alex,
> >> > >> > > > > >
> >> > >> > > > > > My comments was only about the protocol. Getting current
> >> info
> >> > >> about
> >> > >> > > > > > transaction should be handled by the client itself. It is
> >> not
> >> > >> > > protocl's
> >> > >> > > > > > concern. Same about other APIs and behavior in case another
> >> > >> > > transaction
> >> > >> > > > > is
> >> > >> > > > > > attempted from the same thread.
> >> > >> > > > > >
> >> > >> > > > > > Putting protocol aside, transaction support is complicated
> >> > >> matter.
> >> > >> > I
> >> > >> > > > > would
> >> > >> > > > > > propose to route through IEP and wide community
> >> discussion. We
> >> > >> need
> >> > >> > > to
> >> > >> > > > > > review API and semantics very carefully, taking
> >> SUSPEND/RESUME
> >> > >> in
> >> > >> > > > count.
> >> > >> > > > > > Also I do not see how we support client transactions
> >> > efficiently
> >> > >> > > > without
> >> > >> > > > > > decoupling transactions from threads on the server side
> >> first.
> >> > >> > > Because
> >> > >> > > > > > without it you will need a dedicated server thread for
> >> every
> >> > >> > client's
> >> > >> > > > > > transaction which is slow and may even crash the server.
> >> > >> > > > > >
> >> > >> > > > > > Vladimir.
> >> > >> > > > > >
> >> > >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> >> > >> > > > [hidden email]>
> >> > >> > > > > > wrote:
> >> > >> > > > > >
> >> > >> > > > > > > Vladimir, what if we want to get current transaction info
> >> > >> (tx()
> >> > >> > > > > method)?
> >> > >> > > > > > >
> >> > >> > > > > > > Does close() method mapped to TX_END(rollback)?
> >> > >> > > > > > >
> >> > >> > > > > > > For example, this code:
> >> > >> > > > > > >
> >> > >> > > > > > > try(tx = txStart()) {
> >> > >> > > > > > >     tx.commit();
> >> > >> > > > > > > }
> >> > >> > > > > > >
> >> > >> > > > > > > Will produce:
> >> > >> > > > > > > TX_START
> >> > >> > > > > > > TX_END(commit)
> >> > >> > > > > > > TX_END(rollback)
> >> > >> > > > > > >
> >> > >> > > > > > > Am I understand you right?
> >> > >> > > > > > >
> >> > >> > > > > > > About xid. There is yet another proposal. Use some unique
> >> > per
> >> > >> > > > > connection
> >> > >> > > > > > id
> >> > >> > > > > > > (integer, simple counter) for identifying the
> >> transaction on
> >> > >> > > > > > > commit/rollback message. The client gets this id from the
> >> > >> server
> >> > >> > > with
> >> > >> > > > > > > transaction info and sends it back to the server when
> >> trying
> >> > >> to
> >> > >> > > > > > > commit/rollback transaction. This id is not shown to
> >> users.
> >> > >> But
> >> > >> > > also
> >> > >> > > > we
> >> > >> > > > > > can
> >> > >> > > > > > > pass from server to client real transaction id (xid) with
> >> > >> > > transaction
> >> > >> > > > > > info
> >> > >> > > > > > > for diagnostic purposes.
> >> > >> > > > > > >
> >> > >> > > > > > > And one more question: what should we do if the client
> >> > starts
> >> > >> a
> >> > >> > new
> >> > >> > > > > > > transaction without ending the old one? Should we end the
> >> > old
> >> > >> > > > > transaction
> >> > >> > > > > > > implicitly (rollback) or throw an exception to the
> >> client?
> >> > In
> >> > >> my
> >> > >> > > > > opinion,
> >> > >> > > > > > > the first option is better. For example, if we got a
> >> > >> previously
> >> > >> > > used
> >> > >> > > > > > > connection from the connection pool, we should not worry
> >> > about
> >> > >> > any
> >> > >> > > > > > > uncompleted transaction started by the previous user of
> >> this
> >> > >> > > > > connection.
> >> > >> > > > > > >
> >> > >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> >> > >> > [hidden email]
> >> > >> > > >:
> >> > >> > > > > > >
> >> > >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not support
> >> > them
> >> > >> > yet,
> >> > >> > > > and
> >> > >> > > > > > > adding
> >> > >> > > > > > > > them in future should not conflict with simple
> >> START/END
> >> > >> > > > > > infrastructure.
> >> > >> > > > > > > >
> >> > >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> >> > >> > > > > [hidden email]
> >> > >> > > > > > >
> >> > >> > > > > > > > wrote:
> >> > >> > > > > > > >
> >> > >> > > > > > > > > Hi Alex,
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be
> >> enough
> >> > to
> >> > >> > have
> >> > >> > > > > only
> >> > >> > > > > > > two?
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > START - accepts optional parameters, returns
> >> transaction
> >> > >> info
> >> > >> > > > > > > > > END - provides commit flag, returns void
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > Vladimir.
> >> > >> > > > > > > > >
> >> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> >> > >> > > > > > [hidden email]
> >> > >> > > > > > > >
> >> > >> > > > > > > > > wrote:
> >> > >> > > > > > > > >
> >> > >> > > > > > > > >> Sergey, yes, the close is something like silent
> >> > rollback.
> >> > >> > But
> >> > >> > > we
> >> > >> > > > > can
> >> > >> > > > > > > > >> also implement this on the client side, just using
> >> > >> rollback
> >> > >> > > and
> >> > >> > > > > > > ignoring
> >> > >> > > > > > > > >> errors in the response.
> >> > >> > > > > > > > >>
> >> > >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> >> > >> > > > [hidden email]
> >> > >> > > > > >:
> >> > >> > > > > > > > >>
> >> > >> > > > > > > > >> > Nikolay
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > Am I correctly understand you points:
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> >    - close: rollback
> >> > >> > > > > > > > >> >    - commit, close: do nothing
> >> > >> > > > > > > > >> >    - rollback, close: do what? (I suppose nothing)
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > Also you assume that after commit/rollback we may
> >> > need
> >> > >> to
> >> > >> > > free
> >> > >> > > > > > some
> >> > >> > > > > > > > >> > resources on server node(s)or just do on client
> >> > started
> >> > >> > TX?
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex Plehanov <
> >> > >> > > > > > > > [hidden email]
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > wrote:
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > > Sergey, we have the close() method in the thick
> >> > >> client,
> >> > >> > > it's
> >> > >> > > > > > > > behavior
> >> > >> > > > > > > > >> is
> >> > >> > > > > > > > >> > > slightly different than rollback() method (it
> >> > should
> >> > >> > > > rollback
> >> > >> > > > > if
> >> > >> > > > > > > the
> >> > >> > > > > > > > >> > > transaction is not committed and do nothing if
> >> the
> >> > >> > > > transaction
> >> > >> > > > > > is
> >> > >> > > > > > > > >> already
> >> > >> > > > > > > > >> > > committed). I think we should support
> >> > >> try-with-resource
> >> > >> > > > > > semantics
> >> > >> > > > > > > in
> >> > >> > > > > > > > >> the
> >> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful here.
> >> > >> > > > > > > > >> > >
> >> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
> >> > >> pessimistic
> >> > >> > > > > > > > transactions.
> >> > >> > > > > > > > >> > Also,
> >> > >> > > > > > > > >> > > the main goal of suspend/resume operations is to
> >> > >> support
> >> > >> > > > > > > transaction
> >> > >> > > > > > > > >> > > passing between threads. In the thin client, the
> >> > >> > > transaction
> >> > >> > > > > is
> >> > >> > > > > > > > bound
> >> > >> > > > > > > > >> to
> >> > >> > > > > > > > >> > > the client connection, not client thread. I
> >> think
> >> > >> > passing
> >> > >> > > a
> >> > >> > > > > > > > >> transaction
> >> > >> > > > > > > > >> > > between different client connections is not a
> >> very
> >> > >> > useful
> >> > >> > > > > case.
> >> > >> > > > > > > > >> > >
> >> > >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay Izhikov <
> >> > >> > > > > > [hidden email]
> >> > >> > > > > > > >:
> >> > >> > > > > > > > >> > >
> >> > >> > > > > > > > >> > > > Hello, Alex.
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > We also have suspend and resume operations.
> >> > >> > > > > > > > >> > > > I think we should support them
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov <
> >> > >> > > > > > [hidden email]
> >> > >> > > > > > > >:
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > > Hi
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > > Looks like I missed something but why we
> >> need
> >> > >> > > > OP_TX_CLOSE
> >> > >> > > > > > > > >> operation?
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > > Also I suggest to reserve a code for
> >> SAVEPOINT
> >> > >> > > operation
> >> > >> > > > > > which
> >> > >> > > > > > > > >> very
> >> > >> > > > > > > > >> > > > useful
> >> > >> > > > > > > > >> > > > > to understand where transaction has been
> >> rolled
> >> > >> back
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex
> >> Plehanov <
> >> > >> > > > > > > > >> > [hidden email]
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > > > > wrote:
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > > > Hello Igniters!
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > I want to pick up the ticket IGNITE-7369
> >> and
> >> > >> add
> >> > >> > > > > > > transactions
> >> > >> > > > > > > > >> > support
> >> > >> > > > > > > > >> > > > to
> >> > >> > > > > > > > >> > > > > > our thin client implementation.
> >> > >> > > > > > > > >> > > > > > I've looked at our current implementation
> >> and
> >> > >> have
> >> > >> > > > some
> >> > >> > > > > > > > >> proposals
> >> > >> > > > > > > > >> > to
> >> > >> > > > > > > > >> > > > > > support transactions:
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > Add new operations to thin client
> >> protocol:
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current
> >> transaction
> >> > >> for
> >> > >> > > > client
> >> > >> > > > > > > > >> connection
> >> > >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
> >> > transaction
> >> > >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit transaction
> >> > >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
> >> > transaction
> >> > >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close transaction
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > From the client side (java) new interfaces
> >> > >> will be
> >> > >> > > > > added:
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > public interface ClientTransactions {
> >> > >> > > > > > > > >> > > > > >     public ClientTransaction txStart();
> >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> >> > >> > > > > > txStart(TransactionConcurrency
> >> > >> > > > > > > > >> > > > concurrency,
> >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation);
> >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> >> > >> > > > > > txStart(TransactionConcurrency
> >> > >> > > > > > > > >> > > > concurrency,
> >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation, long
> >> timeout,
> >> > >> int
> >> > >> > > > > txSize);
> >> > >> > > > > > > > >> > > > > >     public ClientTransaction tx(); // Get
> >> > >> current
> >> > >> > > > > > connection
> >> > >> > > > > > > > >> > > > transaction
> >> > >> > > > > > > > >> > > > > >     public ClientTransactions
> >> > withLabel(String
> >> > >> > lb);
> >> > >> > > > > > > > >> > > > > > }
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > public interface ClientTransaction extends
> >> > >> > > > > AutoCloseable {
> >> > >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we need
> >> > it?
> >> > >> > > > > > > > >> > > > > >     public TransactionIsolation
> >> isolation();
> >> > >> > > > > > > > >> > > > > >     public TransactionConcurrency
> >> > >> concurrency();
> >> > >> > > > > > > > >> > > > > >     public long timeout();
> >> > >> > > > > > > > >> > > > > >     public String label();
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > >     public void commit();
> >> > >> > > > > > > > >> > > > > >     public void rollback();
> >> > >> > > > > > > > >> > > > > >     public void close();
> >> > >> > > > > > > > >> > > > > > }
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > From the server side, I think as a first
> >> step
> >> > >> > (while
> >> > >> > > > > > > > >> transactions
> >> > >> > > > > > > > >> > > > > > suspend/resume is not fully implemented)
> >> we
> >> > can
> >> > >> > use
> >> > >> > > > the
> >> > >> > > > > > same
> >> > >> > > > > > > > >> > approach
> >> > >> > > > > > > > >> > > > as
> >> > >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> >> > >> > > > ClientRequestHandler
> >> > >> > > > > > and
> >> > >> > > > > > > > >> process
> >> > >> > > > > > > > >> > > > > > requests by this worker if the
> >> transaction is
> >> > >> > > started
> >> > >> > > > > > > > >> explicitly.
> >> > >> > > > > > > > >> > > > > > ClientRequestHandler is bound to client
> >> > >> > connection,
> >> > >> > > so
> >> > >> > > > > > there
> >> > >> > > > > > > > >> will
> >> > >> > > > > > > > >> > be
> >> > >> > > > > > > > >> > > > 1:1
> >> > >> > > > > > > > >> > > > > > relation between client connection and
> >> > thread,
> >> > >> > which
> >> > >> > > > > > process
> >> > >> > > > > > > > >> > > operations
> >> > >> > > > > > > > >> > > > > in
> >> > >> > > > > > > > >> > > > > > a transaction.
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > Also, there is a couple of issues I want
> >> to
> >> > >> > discuss:
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > We have overloaded method txStart with a
> >> > >> different
> >> > >> > > set
> >> > >> > > > > of
> >> > >> > > > > > > > >> > arguments.
> >> > >> > > > > > > > >> > > > Some
> >> > >> > > > > > > > >> > > > > > of the arguments may be missing. To pass
> >> > >> arguments
> >> > >> > > > with
> >> > >> > > > > > > > >> OP_TX_START
> >> > >> > > > > > > > >> > > > > > operation we have the next options:
> >> > >> > > > > > > > >> > > > > >  * Serialize full set of arguments and use
> >> > some
> >> > >> > > value
> >> > >> > > > > for
> >> > >> > > > > > > > >> missing
> >> > >> > > > > > > > >> > > > > > arguments. For example -1 for int/long
> >> types
> >> > >> and
> >> > >> > > null
> >> > >> > > > > for
> >> > >> > > > > > > > string
> >> > >> > > > > > > > >> > > type.
> >> > >> > > > > > > > >> > > > We
> >> > >> > > > > > > > >> > > > > > can't use 0 for int/long types since 0
> >> it's a
> >> > >> > valid
> >> > >> > > > > value
> >> > >> > > > > > > for
> >> > >> > > > > > > > >> > > > > concurrency,
> >> > >> > > > > > > > >> > > > > > isolation and timeout arguments.
> >> > >> > > > > > > > >> > > > > >  * Serialize arguments as a collection of
> >> > >> > > > property-value
> >> > >> > > > > > > pairs
> >> > >> > > > > > > > >> > (like
> >> > >> > > > > > > > >> > > > it's
> >> > >> > > > > > > > >> > > > > > implemented now for CacheConfiguration).
> >> In
> >> > >> this
> >> > >> > > case
> >> > >> > > > > only
> >> > >> > > > > > > > >> > explicitly
> >> > >> > > > > > > > >> > > > > > provided arguments will be serialized.
> >> > >> > > > > > > > >> > > > > > Which way is better? The simplest
> >> solution is
> >> > >> to
> >> > >> > use
> >> > >> > > > the
> >> > >> > > > > > > first
> >> > >> > > > > > > > >> > option
> >> > >> > > > > > > > >> > > > > and I
> >> > >> > > > > > > > >> > > > > > want to use it if there were no
> >> objections.
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > Do we need transaction id (xid) on the
> >> client
> >> > >> > side?
> >> > >> > > > > > > > >> > > > > > If yes, we can pass xid along with
> >> > >> OP_TX_COMMIT,
> >> > >> > > > > > > > OP_TX_ROLLBACK,
> >> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the server
> >> and
> >> > >> do
> >> > >> > > > > > additional
> >> > >> > > > > > > > >> check
> >> > >> > > > > > > > >> > on
> >> > >> > > > > > > > >> > > > the
> >> > >> > > > > > > > >> > > > > > server side (current transaction id for
> >> > >> connection
> >> > >> > > ==
> >> > >> > > > > > > > >> transaction
> >> > >> > > > > > > > >> > id
> >> > >> > > > > > > > >> > > > > passed
> >> > >> > > > > > > > >> > > > > > from client side). This, perhaps, will
> >> > protect
> >> > >> > > clients
> >> > >> > > > > > > against
> >> > >> > > > > > > > >> some
> >> > >> > > > > > > > >> > > > > errors
> >> > >> > > > > > > > >> > > > > > (for example when client try to commit
> >> > outdated
> >> > >> > > > > > > transaction).
> >> > >> > > > > > > > >> But
> >> > >> > > > > > > > >> > > > > > currently, we don't have data type
> >> IgniteUuid
> >> > >> in
> >> > >> > > thin
> >> > >> > > > > > client
> >> > >> > > > > > > > >> > > protocol.
> >> > >> > > > > > > > >> > > > Do
> >> > >> > > > > > > > >> > > > > > we need to add it too?
> >> > >> > > > > > > > >> > > > > > Also, we can pass xid as a string just to
> >> > >> inform
> >> > >> > the
> >> > >> > > > > > client
> >> > >> > > > > > > > and
> >> > >> > > > > > > > >> do
> >> > >> > > > > > > > >> > > not
> >> > >> > > > > > > > >> > > > > pass
> >> > >> > > > > > > > >> > > > > > it back to the server with commit/rollback
> >> > >> > > operation.
> >> > >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick
> >> client
> >> > >> works
> >> > >> > > > this
> >> > >> > > > > > way
> >> > >> > > > > > > as
> >> > >> > > > > > > > >> far
> >> > >> > > > > > > > >> > > as I
> >> > >> > > > > > > > >> > > > > > know).
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > What do you think?
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir
> >> Ozerov <
> >> > >> > > > > > > > >> [hidden email]
> >> > >> > > > > > > > >> > >:
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > > > > We already have transactions support in
> >> > JDBC
> >> > >> > > driver
> >> > >> > > > in
> >> > >> > > > > > TX
> >> > >> > > > > > > > SQL
> >> > >> > > > > > > > >> > > branch
> >> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is
> >> implemented
> >> > >> > through
> >> > >> > > > > > > separate
> >> > >> > > > > > > > >> > thread,
> >> > >> > > > > > > > >> > > > > which
> >> > >> > > > > > > > >> > > > > > > is not that efficient. Ideally we need
> >> to
> >> > >> finish
> >> > >> > > > > > > decoupling
> >> > >> > > > > > > > >> > > > > transactions
> >> > >> > > > > > > > >> > > > > > > from threads. But alternatively we can
> >> > change
> >> > >> > the
> >> > >> > > > > logic
> >> > >> > > > > > on
> >> > >> > > > > > > > >> how we
> >> > >> > > > > > > > >> > > > > assign
> >> > >> > > > > > > > >> > > > > > > thread ID to specific transaction and
> >> > >> > > "impersonate"
> >> > >> > > > > thin
> >> > >> > > > > > > > >> client
> >> > >> > > > > > > > >> > > > worker
> >> > >> > > > > > > > >> > > > > > > threads when serving requests from
> >> multiple
> >> > >> > users.
> >> > >> > > > > > > > >> > > > > > >
> >> > >> > > > > > > > >> > > > > > >
> >> > >> > > > > > > > >> > > > > > >
> >> > >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM, Denis
> >> > Magda
> >> > >> <
> >> > >> > > > > > > > >> [hidden email]>
> >> > >> > > > > > > > >> > > > > wrote:
> >> > >> > > > > > > > >> > > > > > >
> >> > >> > > > > > > > >> > > > > > > > Here is an original discussion with a
> >> > >> > reference
> >> > >> > > to
> >> > >> > > > > the
> >> > >> > > > > > > > JIRA
> >> > >> > > > > > > > >> > > ticket:
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > http://apache-ignite-developers.2346864.n4.nabble
> >> > >> > > > .
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > >
> >> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> >> > >> > > > > > > > >> > > > > > > > Protocol-td25914.html
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > --
> >> > >> > > > > > > > >> > > > > > > > Denis
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM,
> >> Dmitriy
> >> > >> > > Setrakyan
> >> > >> > > > <
> >> > >> > > > > > > > >> > > > > > [hidden email]
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > wrote:
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we have a
> >> > >> design
> >> > >> > > > > proposal
> >> > >> > > > > > > for
> >> > >> > > > > > > > >> > > > transaction
> >> > >> > > > > > > > >> > > > > > > > support
> >> > >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind taking
> >> > this
> >> > >> > > > > initiative
> >> > >> > > > > > > and
> >> > >> > > > > > > > >> > > creating
> >> > >> > > > > > > > >> > > > an
> >> > >> > > > > > > > >> > > > > > IEP
> >> > >> > > > > > > > >> > > > > > > > on
> >> > >> > > > > > > > >> > > > > > > > > Wiki?
> >> > >> > > > > > > > >> > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > D.
> >> > >> > > > > > > > >> > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM,
> >> Dmitriy
> >> > >> > > > > Govorukhin <
> >> > >> > > > > > > > >> > > > > > > > > [hidden email]>
> >> wrote:
> >> > >> > > > > > > > >> > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> >> > >> > > > > > > > >> > > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions
> >> about
> >> > >> thin
> >> > >> > > > client
> >> > >> > > > > > and
> >> > >> > > > > > > > >> binary
> >> > >> > > > > > > > >> > > > > > protocol,
> >> > >> > > > > > > > >> > > > > > > > > but I
> >> > >> > > > > > > > >> > > > > > > > > > did not hear anything about
> >> > >> transactions
> >> > >> > > > > support.
> >> > >> > > > > > Do
> >> > >> > > > > > > > we
> >> > >> > > > > > > > >> > have
> >> > >> > > > > > > > >> > > > some
> >> > >> > > > > > > > >> > > > > > > draft
> >> > >> > > > > > > > >> > > > > > > > > for
> >> > >> > > > > > > > >> > > > > > > > > > this purpose?
> >> > >> > > > > > > > >> > > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > > As I understand we have several
> >> > >> problems:
> >> > >> > > > > > > > >> > > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > >    - thread and transaction have
> >> hard
> >> > >> > > related
> >> > >> > > > > (we
> >> > >> > > > > > > use
> >> > >> > > > > > > > >> > > > > thread-local
> >> > >> > > > > > > > >> > > > > > > > > variable
> >> > >> > > > > > > > >> > > > > > > > > >    and thread name)
> >> > >> > > > > > > > >> > > > > > > > > >    - we can process only one
> >> > >> transaction
> >> > >> > at
> >> > >> > > > the
> >> > >> > > > > > same
> >> > >> > > > > > > > >> time
> >> > >> > > > > > > > >> > in
> >> > >> > > > > > > > >> > > > one
> >> > >> > > > > > > > >> > > > > > > thread
> >> > >> > > > > > > > >> > > > > > > > > (it
> >> > >> > > > > > > > >> > > > > > > > > >    mean we need hold thread per
> >> > >> client. If
> >> > >> > > > > connect
> >> > >> > > > > > > 100
> >> > >> > > > > > > > >> thin
> >> > >> > > > > > > > >> > > > > clients
> >> > >> > > > > > > > >> > > > > > > to
> >> > >> > > > > > > > >> > > > > > > > 1
> >> > >> > > > > > > > >> > > > > > > > > >    server node, then need to hold
> >> 100
> >> > >> > thread
> >> > >> > > > on
> >> > >> > > > > > the
> >> > >> > > > > > > > >> server
> >> > >> > > > > > > > >> > > > side)
> >> > >> > > > > > > > >> > > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > > > Let's discuss how we can implement
> >> > >> > > > transactions
> >> > >> > > > > > for
> >> > >> > > > > > > > the
> >> > >> > > > > > > > >> > thin
> >> > >> > > > > > > > >> > > > > > client.
> >> > >> > > > > > > > >> > > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > > >
> >> > >> > > > > > > > >> > > > > > > >
> >> > >> > > > > > > > >> > > > > > >
> >> > >> > > > > > > > >> > > > > >
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > > > --
> >> > >> > > > > > > > >> > > > > Sergey Kozlov
> >> > >> > > > > > > > >> > > > > GridGain Systems
> >> > >> > > > > > > > >> > > > > www.gridgain.com
> >> > >> > > > > > > > >> > > > >
> >> > >> > > > > > > > >> > > >
> >> > >> > > > > > > > >> > >
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >> > --
> >> > >> > > > > > > > >> > Sergey Kozlov
> >> > >> > > > > > > > >> > GridGain Systems
> >> > >> > > > > > > > >> > www.gridgain.com
> >> > >> > > > > > > > >> >
> >> > >> > > > > > > > >>
> >> > >> > > > > > > > >
> >> > >> > > > > > > >
> >> > >> > > > > > >
> >> > >> > > > > >
> >> > >> > > > >
> >> > >> > > >
> >> > >> > >
> >> > >> >
> >> > >>
> >> > >
> >> >
> >>
> >

--
Best regards,
Ivan Pavlukhin

[Alexey Plekhanov]

Hi, Ivan.

Thanks for your comments.

1. Transaction id in thin client protocol it's just a tx counter for the
current connection. It's not related to GridCacheVersion. If we want to
know GridCacheVersion on the client side, I think we should introduce a new
type of operation (for example OP_TX_INFO).
2. Error handling is already provided by thin client protocol, even in case
of empty response. Of course, the client will know if there is a failure
occurred during OP_TX_END operation.
3. AFAIK some of thin client implementations already send requests and
process responses in an async way (.NET for example). As for java thin
client, in the current implementation channel is locked exclusively before
request send and until the response is processed. I have some ideas about
how to fix this (split send/receive process into two different parts and
acquire locks for this parts separately or create futures on request sent
and complete it after processing the response in a dedicated thread), I've
created ticket [1] for this issue and will try to implement prototype in a
couple of days.

About suspend/resume, yes, on server-side we should resume tx before each
transactional cache operation and suspend the tx after the operation. In my
opinion, suspend/resume approach have several advantages over approach with
explicit tx id argument:
- Introducing explicit tx id argument for cache operations leads to a
significant API change
- It's not clear how to use it together with current (tx-per-thread)
approach (for example, what if a thread is already held transaction and
someone call cache operation with explicit tx id?)
- Suspend/resume feature will also be useful for thick clients
- Suspend/resume functionality is already partially implemented (for
optimistic transactions only)

[1] https://issues.apache.org/jira/browse/IGNITE-11685

пт, 3 мая 2019 г. в 08:10, Павлухин Иван <[hidden email]>:

> Hi Alex,
>
> I went through IEP [1] and I have a couple of questions:
> 1. What is going to be used as transaction id? In a described protocol
> I see an int field for it. Should not it be GridCacheVersion
> corresponding to IgniteInternalTx#xidVersion?
> 2. OP_TX_END message assumes an empty response, but I think that
> errors during tx finish are possible and should be returned in a
> response.
> 3. In IEP it is stated that async processing of lock operations should
> be introduced on a client side to enable concurrent operations from
> different client threads. Do you have an idea how to achieve it?
>
> Also, a bit about a suspend/resume trait. I tried to think about it
> leaving away an existing transactions implementation in Ignite. As I
> understood we are going to resume a tx before each cache operation in
> the tx and resume the tx after the operation. All this to make an
> executing thread available for other operations (e.g. in other txs).
> From the first glance it seems like an inversed logic. A
> straightforward way is to execute a cache operation within a
> particular transaction defined as an explicit tx id argument (e.g.
> cache.put(key, value, txid)). Can we do so?
>
> And leaving for now thin client API. I cannot say that one proposed in
> IEP is good or bad. I can only say that it ressembles current thick
> client API. And perhaps it should not. I think that we should consider
> similar APIs provided by other vendors and keep in mind that we have a
> bunch of client implementations for different languages. I suppose
> that we can return to it a little bit later. And I hope that we will
> do it.
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
>
> вт, 30 апр. 2019 г. в 13:24, Alex Plehanov <[hidden email]>:
> >
> > Hello, Igniters!
> >
> > I've update IEP [1] and implement PoC according to new approach (multiple
> > concurrent transactions per connection).
> > But to move forward another feature need to be implemented:
> suspend/resume
> > for pessimistic transactions (IGNITE-5714 [2]). Implementation of
> > suspend/resume is ready now and ticket in 'Patch available' status. Can
> any
> > transactions expert help with review of IGNITE-5714?
> >
> > [1]:
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > [2]: https://issues.apache.org/jira/browse/IGNITE-5714
> >
> > чт, 4 апр. 2019 г. в 11:32, Alex Plehanov <[hidden email]>:
> >
> > > Vladimir,
> > >
> > > Ok, then I will rewrite IEP in the near future.
> > >
> > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <[hidden email]>:
> > >
> > >> Hi Alex,
> > >>
> > >> I think we should be able to handle many transactions through a single
> > >> connection. This will make our protocol and client implementations
> much
> > >> more efficient, and simplicity from developer's perspective is not our
> > >> goal. Consider normal nodes. We have server nodes and client nodes.
> You
> > >> may
> > >> span whatever number of transactions you need, but all of them are
> > >> coordinated through a single connection. The same should be
> applicable to
> > >> thin clients. Protocol is already designed to handle this, as we pass
> > >> unique operation ID in order to distinguish one operation from
> another. It
> > >> is true, though, that we will have to introduce a kind of "session"
> > >> concept, and pass additional identifier along with cache operations,
> but
> > >> this doesn't sound like a problem to me.
> > >>
> > >> And provided that currently server-side transactions are bound to
> threads
> > >> artificially, I would say that the first step in implementation of
> > >> transactions on thin clients should be decoupling server-side
> transactions
> > >> from threads. Without this we will have very inefficient
> implementation,
> > >> when every new client transaction have to spawn a new thread. This is
> slow
> > >> and introduces high memory pressure on a cluster node. We already work
> > >> this
> > >> way for MVCC transactions which are spawned from JDBC driver, and
> believe
> > >> me, we do not want to replicated this bad practice to other clients
> :-)
> > >>
> > >> Vladimir.
> > >>
> > >> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <
> [hidden email]>
> > >> wrote:
> > >>
> > >> > Guys, so, do we need multiple concurrent transactions per
> connection?
> > >> >
> > >> > There are pros and cons for each approach. Difference between
> > >> approaches:
> > >> >
> > >> > One transaction at a time per connection:
> > >> >  - This approach is used in RDBMS world and users got used to it
> > >> >  - To use transactions concurrently users need to use different
> > >> connections
> > >> > and get these connections via something like a connection pool
> > >> >  - Easy to implement (in fact, PoC is already done)
> > >> >
> > >> > Multiple concurrent transactions per connection:
> > >> >  - At least for java thin client, we can implement transaction per
> > >> thread
> > >> > approach as implemented now for the thick client (perhaps other thin
> > >> > clients can implement the same abstraction)
> > >> >  - There is also protocol change for all cache operations needed (to
> > >> bind
> > >> > cache operation to the transaction)
> > >> >  - Significant changes to all implemented clients are needed
> > >> >  - Implementation on the server side is more complex
> > >> >
> > >> > What do you think?
> > >> >
> > >> >
> > >> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <[hidden email]
> >:
> > >> >
> > >> > > Ilya,
> > >> > >
> > >> > > > We should be able to multiplex several transactions using a
> single
> > >> > > Client connection.
> > >> > > In this case, we should significantly change cache operations
> syntax
> > >> (for
> > >> > > each implemented client), to bind each operation to the
> transaction.
> > >> > >
> > >> > > > I want to also ask if "Number of entries participating in
> > >> transaction
> > >> > > (may be approximate). 0 - default value." is needed.
> > >> > > I've tried to minimize API changes between thick and thin client
> to
> > >> > > simplify move from one to another. It's the only reason. But I
> agree
> > >> with
> > >> > > you, the parameter is not very useful.
> > >> > >
> > >> > >
> > >> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <
> > >> [hidden email]>:
> > >> > >
> > >> > >> Hello!
> > >> > >>
> > >> > >> Pavel, I agree with you thorougly. We should be able to multiplex
> > >> > several
> > >> > >> transactions using a single Client connection. This means adding
> > >> > >> Transaction id parameter to every affected cache operation / SQL
> > >> > statement
> > >> > >> (if applicable) to make sure we do cache operations on relevant
> > >> > >> transaction.
> > >> > >>
> > >> > >> This is how other things work in Ignite, such as communication.
> We do
> > >> > not
> > >> > >> open dozens of connections, we multiplex operations
> asynchronously
> > >> > through
> > >> > >> a single connection.
> > >> > >>
> > >> > >> I think that trying to pool Ignite connections will be highly
> > >> > >> inconvenient,
> > >> > >> since there is no existing infrastructure for such pooling (like
> > >> there
> > >> > >> exists for JDBC).
> > >> > >>
> > >> > >> I want to also ask if "Number of entries participating in
> transaction
> > >> > (may
> > >> > >> be approximate). 0 - default value." is needed. Does it actually
> do
> > >> > >> anything in our tx protocol? Users of existing APIs are already
> > >> confused
> > >> > >> by
> > >> > >> this parameter, if we could get rid of it in thin client
> protocol it
> > >> > would
> > >> > >> be nice clean-up.
> > >> > >>
> > >> > >> Regards,
> > >> > >> --
> > >> > >> Ilya Kasnacheev
> > >> > >>
> > >> > >>
> > >> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <[hidden email]
> >:
> > >> > >>
> > >> > >> > Alex,
> > >> > >> >
> > >> > >> > > now we can only support one active transaction per connection
> > >> > >> >
> > >> > >> > I totally understand server-side and protocol limitations that
> are
> > >> > >> causing
> > >> > >> > this.
> > >> > >> > But I have no idea how to support this in .NET Thin Client, for
> > >> > example.
> > >> > >> >
> > >> > >> > It is thread-safe and can handle multiple async operations in
> > >> > parallel.
> > >> > >> > But with TX support we have to somehow switch to
> single-threaded
> > >> mode
> > >> > to
> > >> > >> > avoid unexpected effects.
> > >> > >> >
> > >> > >> > Any ideas?
> > >> > >> >
> > >> > >> >
> > >> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <
> > >> [hidden email]
> > >> > >
> > >> > >> > wrote:
> > >> > >> >
> > >> > >> > > Dmitriy, thank you!
> > >> > >> > >
> > >> > >> > > Guys, I've created the IEP [1] on wiki, please have a look.
> > >> > >> > >
> > >> > >> > > [1]
> > >> > >> > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> >
> > >>
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >> > >> > >
> > >> > >> > >
> > >> > >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <
> [hidden email]
> > >> >:
> > >> > >> > >
> > >> > >> > > > Hi,
> > >> > >> > > >
> > >> > >> > > > I've added permissions to account plehanov.alex
> > >> > >> > > >
> > >> > >> > > > Recently Infra integrated Apache LDAP with confluence, so
> it is
> > >> > >> > possible
> > >> > >> > > to
> > >> > >> > > > login using Apache credentials. Probably we can ask infra
> if
> > >> extra
> > >> > >> > > > permissions to edit pages should be added for committers.
> > >> > >> > > >
> > >> > >> > > > Sincerely,
> > >> > >> > > > Dmitriy Pavlov
> > >> > >> > > >
> > >> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
> > >> > [hidden email]
> > >> > >> >:
> > >> > >> > > >
> > >> > >> > > > > Vladimir,
> > >> > >> > > > >
> > >> > >> > > > > About current tx: ok, then we don't need tx() method in
> the
> > >> > >> interface
> > >> > >> > > at
> > >> > >> > > > > all (the same cached transaction info user can store by
> > >> > himself).
> > >> > >> > > > >
> > >> > >> > > > > About decoupling transactions from threads on the server
> > >> side:
> > >> > for
> > >> > >> > now,
> > >> > >> > > > we
> > >> > >> > > > > can start with thread-per-connection approach (we only
> can
> > >> > support
> > >> > >> > one
> > >> > >> > > > > active transaction per connection, see below, so we need
> one
> > >> > >> > additional
> > >> > >> > > > > dedicated thread for each connection with active
> > >> transaction),
> > >> > and
> > >> > >> > > later
> > >> > >> > > > > change server-side internals to process client
> transactions
> > >> in
> > >> > any
> > >> > >> > > server
> > >> > >> > > > > thread (not dedicated to this connection). This change
> will
> > >> not
> > >> > >> > affect
> > >> > >> > > > the
> > >> > >> > > > > thin client protocol, it only affects the server side.
> > >> > >> > > > > In any case, we can't support concurrent transactions per
> > >> > >> connection
> > >> > >> > on
> > >> > >> > > > > the client side without fundamental changes to the
> current
> > >> > >> protocol
> > >> > >> > > > (cache
> > >> > >> > > > > operation doesn't bound to transaction or thread and the
> > >> server
> > >> > >> > doesn't
> > >> > >> > > > > know which thread on the client side do this cache
> > >> operation).
> > >> > In
> > >> > >> my
> > >> > >> > > > > opinion, if a user wants to use concurrent transactions,
> he
> > >> must
> > >> > >> use
> > >> > >> > > > > different connections from a connection pool.
> > >> > >> > > > >
> > >> > >> > > > > About semantics of suspend/resume on the client-side:
> it's
> > >> > >> absolutely
> > >> > >> > > > > different than server-side semantics (we don't need to do
> > >> > >> > > suspend/resume
> > >> > >> > > > to
> > >> > >> > > > > pass transaction between threads on the client-side), but
> > >> can't
> > >> > be
> > >> > >> > > > > implemented efficiently without implemented
> suspend/resume on
> > >> > >> > > > server-side.
> > >> > >> > > > >
> > >> > >> > > > > Can anyone give me permissions to create IEP on Apache
> wiki?
> > >> > >> > > > >
> > >> > >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
> > >> > >> [hidden email]>:
> > >> > >> > > > >
> > >> > >> > > > > > Hi Alex,
> > >> > >> > > > > >
> > >> > >> > > > > > My comments was only about the protocol. Getting
> current
> > >> info
> > >> > >> about
> > >> > >> > > > > > transaction should be handled by the client itself. It
> is
> > >> not
> > >> > >> > > protocl's
> > >> > >> > > > > > concern. Same about other APIs and behavior in case
> another
> > >> > >> > > transaction
> > >> > >> > > > > is
> > >> > >> > > > > > attempted from the same thread.
> > >> > >> > > > > >
> > >> > >> > > > > > Putting protocol aside, transaction support is
> complicated
> > >> > >> matter.
> > >> > >> > I
> > >> > >> > > > > would
> > >> > >> > > > > > propose to route through IEP and wide community
> > >> discussion. We
> > >> > >> need
> > >> > >> > > to
> > >> > >> > > > > > review API and semantics very carefully, taking
> > >> SUSPEND/RESUME
> > >> > >> in
> > >> > >> > > > count.
> > >> > >> > > > > > Also I do not see how we support client transactions
> > >> > efficiently
> > >> > >> > > > without
> > >> > >> > > > > > decoupling transactions from threads on the server side
> > >> first.
> > >> > >> > > Because
> > >> > >> > > > > > without it you will need a dedicated server thread for
> > >> every
> > >> > >> > client's
> > >> > >> > > > > > transaction which is slow and may even crash the
> server.
> > >> > >> > > > > >
> > >> > >> > > > > > Vladimir.
> > >> > >> > > > > >
> > >> > >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > >> > >> > > > [hidden email]>
> > >> > >> > > > > > wrote:
> > >> > >> > > > > >
> > >> > >> > > > > > > Vladimir, what if we want to get current transaction
> info
> > >> > >> (tx()
> > >> > >> > > > > method)?
> > >> > >> > > > > > >
> > >> > >> > > > > > > Does close() method mapped to TX_END(rollback)?
> > >> > >> > > > > > >
> > >> > >> > > > > > > For example, this code:
> > >> > >> > > > > > >
> > >> > >> > > > > > > try(tx = txStart()) {
> > >> > >> > > > > > >     tx.commit();
> > >> > >> > > > > > > }
> > >> > >> > > > > > >
> > >> > >> > > > > > > Will produce:
> > >> > >> > > > > > > TX_START
> > >> > >> > > > > > > TX_END(commit)
> > >> > >> > > > > > > TX_END(rollback)
> > >> > >> > > > > > >
> > >> > >> > > > > > > Am I understand you right?
> > >> > >> > > > > > >
> > >> > >> > > > > > > About xid. There is yet another proposal. Use some
> unique
> > >> > per
> > >> > >> > > > > connection
> > >> > >> > > > > > id
> > >> > >> > > > > > > (integer, simple counter) for identifying the
> > >> transaction on
> > >> > >> > > > > > > commit/rollback message. The client gets this id
> from the
> > >> > >> server
> > >> > >> > > with
> > >> > >> > > > > > > transaction info and sends it back to the server when
> > >> trying
> > >> > >> to
> > >> > >> > > > > > > commit/rollback transaction. This id is not shown to
> > >> users.
> > >> > >> But
> > >> > >> > > also
> > >> > >> > > > we
> > >> > >> > > > > > can
> > >> > >> > > > > > > pass from server to client real transaction id (xid)
> with
> > >> > >> > > transaction
> > >> > >> > > > > > info
> > >> > >> > > > > > > for diagnostic purposes.
> > >> > >> > > > > > >
> > >> > >> > > > > > > And one more question: what should we do if the
> client
> > >> > starts
> > >> > >> a
> > >> > >> > new
> > >> > >> > > > > > > transaction without ending the old one? Should we
> end the
> > >> > old
> > >> > >> > > > > transaction
> > >> > >> > > > > > > implicitly (rollback) or throw an exception to the
> > >> client?
> > >> > In
> > >> > >> my
> > >> > >> > > > > opinion,
> > >> > >> > > > > > > the first option is better. For example, if we got a
> > >> > >> previously
> > >> > >> > > used
> > >> > >> > > > > > > connection from the connection pool, we should not
> worry
> > >> > about
> > >> > >> > any
> > >> > >> > > > > > > uncompleted transaction started by the previous user
> of
> > >> this
> > >> > >> > > > > connection.
> > >> > >> > > > > > >
> > >> > >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> > >> > >> > [hidden email]
> > >> > >> > > >:
> > >> > >> > > > > > >
> > >> > >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not
> support
> > >> > them
> > >> > >> > yet,
> > >> > >> > > > and
> > >> > >> > > > > > > adding
> > >> > >> > > > > > > > them in future should not conflict with simple
> > >> START/END
> > >> > >> > > > > > infrastructure.
> > >> > >> > > > > > > >
> > >> > >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <
> > >> > >> > > > > [hidden email]
> > >> > >> > > > > > >
> > >> > >> > > > > > > > wrote:
> > >> > >> > > > > > > >
> > >> > >> > > > > > > > > Hi Alex,
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it be
> > >> enough
> > >> > to
> > >> > >> > have
> > >> > >> > > > > only
> > >> > >> > > > > > > two?
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > START - accepts optional parameters, returns
> > >> transaction
> > >> > >> info
> > >> > >> > > > > > > > > END - provides commit flag, returns void
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > Vladimir.
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> > >> > >> > > > > > [hidden email]
> > >> > >> > > > > > > >
> > >> > >> > > > > > > > > wrote:
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > > >> Sergey, yes, the close is something like silent
> > >> > rollback.
> > >> > >> > But
> > >> > >> > > we
> > >> > >> > > > > can
> > >> > >> > > > > > > > >> also implement this on the client side, just
> using
> > >> > >> rollback
> > >> > >> > > and
> > >> > >> > > > > > > ignoring
> > >> > >> > > > > > > > >> errors in the response.
> > >> > >> > > > > > > > >>
> > >> > >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> > >> > >> > > > [hidden email]
> > >> > >> > > > > >:
> > >> > >> > > > > > > > >>
> > >> > >> > > > > > > > >> > Nikolay
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > Am I correctly understand you points:
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> >    - close: rollback
> > >> > >> > > > > > > > >> >    - commit, close: do nothing
> > >> > >> > > > > > > > >> >    - rollback, close: do what? (I suppose
> nothing)
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > Also you assume that after commit/rollback we
> may
> > >> > need
> > >> > >> to
> > >> > >> > > free
> > >> > >> > > > > > some
> > >> > >> > > > > > > > >> > resources on server node(s)or just do on
> client
> > >> > started
> > >> > >> > TX?
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex
> Plehanov <
> > >> > >> > > > > > > > [hidden email]
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > wrote:
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > > Sergey, we have the close() method in the
> thick
> > >> > >> client,
> > >> > >> > > it's
> > >> > >> > > > > > > > behavior
> > >> > >> > > > > > > > >> is
> > >> > >> > > > > > > > >> > > slightly different than rollback() method
> (it
> > >> > should
> > >> > >> > > > rollback
> > >> > >> > > > > if
> > >> > >> > > > > > > the
> > >> > >> > > > > > > > >> > > transaction is not committed and do nothing
> if
> > >> the
> > >> > >> > > > transaction
> > >> > >> > > > > > is
> > >> > >> > > > > > > > >> already
> > >> > >> > > > > > > > >> > > committed). I think we should support
> > >> > >> try-with-resource
> > >> > >> > > > > > semantics
> > >> > >> > > > > > > in
> > >> > >> > > > > > > > >> the
> > >> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful
> here.
> > >> > >> > > > > > > > >> > >
> > >> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet for
> > >> > >> pessimistic
> > >> > >> > > > > > > > transactions.
> > >> > >> > > > > > > > >> > Also,
> > >> > >> > > > > > > > >> > > the main goal of suspend/resume operations
> is to
> > >> > >> support
> > >> > >> > > > > > > transaction
> > >> > >> > > > > > > > >> > > passing between threads. In the thin
> client, the
> > >> > >> > > transaction
> > >> > >> > > > > is
> > >> > >> > > > > > > > bound
> > >> > >> > > > > > > > >> to
> > >> > >> > > > > > > > >> > > the client connection, not client thread. I
> > >> think
> > >> > >> > passing
> > >> > >> > > a
> > >> > >> > > > > > > > >> transaction
> > >> > >> > > > > > > > >> > > between different client connections is not
> a
> > >> very
> > >> > >> > useful
> > >> > >> > > > > case.
> > >> > >> > > > > > > > >> > >
> > >> > >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay
> Izhikov <
> > >> > >> > > > > > [hidden email]
> > >> > >> > > > > > > >:
> > >> > >> > > > > > > > >> > >
> > >> > >> > > > > > > > >> > > > Hello, Alex.
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > We also have suspend and resume
> operations.
> > >> > >> > > > > > > > >> > > > I think we should support them
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey Kozlov
> <
> > >> > >> > > > > > [hidden email]
> > >> > >> > > > > > > >:
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > > Hi
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > > Looks like I missed something but why we
> > >> need
> > >> > >> > > > OP_TX_CLOSE
> > >> > >> > > > > > > > >> operation?
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > > Also I suggest to reserve a code for
> > >> SAVEPOINT
> > >> > >> > > operation
> > >> > >> > > > > > which
> > >> > >> > > > > > > > >> very
> > >> > >> > > > > > > > >> > > > useful
> > >> > >> > > > > > > > >> > > > > to understand where transaction has been
> > >> rolled
> > >> > >> back
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex
> > >> Plehanov <
> > >> > >> > > > > > > > >> > [hidden email]
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > > > > wrote:
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > > > Hello Igniters!
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > I want to pick up the ticket
> IGNITE-7369
> > >> and
> > >> > >> add
> > >> > >> > > > > > > transactions
> > >> > >> > > > > > > > >> > support
> > >> > >> > > > > > > > >> > > > to
> > >> > >> > > > > > > > >> > > > > > our thin client implementation.
> > >> > >> > > > > > > > >> > > > > > I've looked at our current
> implementation
> > >> and
> > >> > >> have
> > >> > >> > > > some
> > >> > >> > > > > > > > >> proposals
> > >> > >> > > > > > > > >> > to
> > >> > >> > > > > > > > >> > > > > > support transactions:
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > Add new operations to thin client
> > >> protocol:
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current
> > >> transaction
> > >> > >> for
> > >> > >> > > > client
> > >> > >> > > > > > > > >> connection
> > >> > >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
> > >> > transaction
> > >> > >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit
> transaction
> > >> > >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
> > >> > transaction
> > >> > >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close
> transaction
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > From the client side (java) new
> interfaces
> > >> > >> will be
> > >> > >> > > > > added:
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > public interface ClientTransactions {
> > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> txStart();
> > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > >> > >> > > > > > txStart(TransactionConcurrency
> > >> > >> > > > > > > > >> > > > concurrency,
> > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation);
> > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > >> > >> > > > > > txStart(TransactionConcurrency
> > >> > >> > > > > > > > >> > > > concurrency,
> > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation, long
> > >> timeout,
> > >> > >> int
> > >> > >> > > > > txSize);
> > >> > >> > > > > > > > >> > > > > >     public ClientTransaction tx(); //
> Get
> > >> > >> current
> > >> > >> > > > > > connection
> > >> > >> > > > > > > > >> > > > transaction
> > >> > >> > > > > > > > >> > > > > >     public ClientTransactions
> > >> > withLabel(String
> > >> > >> > lb);
> > >> > >> > > > > > > > >> > > > > > }
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > public interface ClientTransaction
> extends
> > >> > >> > > > > AutoCloseable {
> > >> > >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do we
> need
> > >> > it?
> > >> > >> > > > > > > > >> > > > > >     public TransactionIsolation
> > >> isolation();
> > >> > >> > > > > > > > >> > > > > >     public TransactionConcurrency
> > >> > >> concurrency();
> > >> > >> > > > > > > > >> > > > > >     public long timeout();
> > >> > >> > > > > > > > >> > > > > >     public String label();
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > >     public void commit();
> > >> > >> > > > > > > > >> > > > > >     public void rollback();
> > >> > >> > > > > > > > >> > > > > >     public void close();
> > >> > >> > > > > > > > >> > > > > > }
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > From the server side, I think as a
> first
> > >> step
> > >> > >> > (while
> > >> > >> > > > > > > > >> transactions
> > >> > >> > > > > > > > >> > > > > > suspend/resume is not fully
> implemented)
> > >> we
> > >> > can
> > >> > >> > use
> > >> > >> > > > the
> > >> > >> > > > > > same
> > >> > >> > > > > > > > >> > approach
> > >> > >> > > > > > > > >> > > > as
> > >> > >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> > >> > >> > > > ClientRequestHandler
> > >> > >> > > > > > and
> > >> > >> > > > > > > > >> process
> > >> > >> > > > > > > > >> > > > > > requests by this worker if the
> > >> transaction is
> > >> > >> > > started
> > >> > >> > > > > > > > >> explicitly.
> > >> > >> > > > > > > > >> > > > > > ClientRequestHandler is bound to
> client
> > >> > >> > connection,
> > >> > >> > > so
> > >> > >> > > > > > there
> > >> > >> > > > > > > > >> will
> > >> > >> > > > > > > > >> > be
> > >> > >> > > > > > > > >> > > > 1:1
> > >> > >> > > > > > > > >> > > > > > relation between client connection and
> > >> > thread,
> > >> > >> > which
> > >> > >> > > > > > process
> > >> > >> > > > > > > > >> > > operations
> > >> > >> > > > > > > > >> > > > > in
> > >> > >> > > > > > > > >> > > > > > a transaction.
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > Also, there is a couple of issues I
> want
> > >> to
> > >> > >> > discuss:
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > We have overloaded method txStart
> with a
> > >> > >> different
> > >> > >> > > set
> > >> > >> > > > > of
> > >> > >> > > > > > > > >> > arguments.
> > >> > >> > > > > > > > >> > > > Some
> > >> > >> > > > > > > > >> > > > > > of the arguments may be missing. To
> pass
> > >> > >> arguments
> > >> > >> > > > with
> > >> > >> > > > > > > > >> OP_TX_START
> > >> > >> > > > > > > > >> > > > > > operation we have the next options:
> > >> > >> > > > > > > > >> > > > > >  * Serialize full set of arguments
> and use
> > >> > some
> > >> > >> > > value
> > >> > >> > > > > for
> > >> > >> > > > > > > > >> missing
> > >> > >> > > > > > > > >> > > > > > arguments. For example -1 for int/long
> > >> types
> > >> > >> and
> > >> > >> > > null
> > >> > >> > > > > for
> > >> > >> > > > > > > > string
> > >> > >> > > > > > > > >> > > type.
> > >> > >> > > > > > > > >> > > > We
> > >> > >> > > > > > > > >> > > > > > can't use 0 for int/long types since 0
> > >> it's a
> > >> > >> > valid
> > >> > >> > > > > value
> > >> > >> > > > > > > for
> > >> > >> > > > > > > > >> > > > > concurrency,
> > >> > >> > > > > > > > >> > > > > > isolation and timeout arguments.
> > >> > >> > > > > > > > >> > > > > >  * Serialize arguments as a
> collection of
> > >> > >> > > > property-value
> > >> > >> > > > > > > pairs
> > >> > >> > > > > > > > >> > (like
> > >> > >> > > > > > > > >> > > > it's
> > >> > >> > > > > > > > >> > > > > > implemented now for
> CacheConfiguration).
> > >> In
> > >> > >> this
> > >> > >> > > case
> > >> > >> > > > > only
> > >> > >> > > > > > > > >> > explicitly
> > >> > >> > > > > > > > >> > > > > > provided arguments will be serialized.
> > >> > >> > > > > > > > >> > > > > > Which way is better? The simplest
> > >> solution is
> > >> > >> to
> > >> > >> > use
> > >> > >> > > > the
> > >> > >> > > > > > > first
> > >> > >> > > > > > > > >> > option
> > >> > >> > > > > > > > >> > > > > and I
> > >> > >> > > > > > > > >> > > > > > want to use it if there were no
> > >> objections.
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > Do we need transaction id (xid) on the
> > >> client
> > >> > >> > side?
> > >> > >> > > > > > > > >> > > > > > If yes, we can pass xid along with
> > >> > >> OP_TX_COMMIT,
> > >> > >> > > > > > > > OP_TX_ROLLBACK,
> > >> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the
> server
> > >> and
> > >> > >> do
> > >> > >> > > > > > additional
> > >> > >> > > > > > > > >> check
> > >> > >> > > > > > > > >> > on
> > >> > >> > > > > > > > >> > > > the
> > >> > >> > > > > > > > >> > > > > > server side (current transaction id
> for
> > >> > >> connection
> > >> > >> > > ==
> > >> > >> > > > > > > > >> transaction
> > >> > >> > > > > > > > >> > id
> > >> > >> > > > > > > > >> > > > > passed
> > >> > >> > > > > > > > >> > > > > > from client side). This, perhaps, will
> > >> > protect
> > >> > >> > > clients
> > >> > >> > > > > > > against
> > >> > >> > > > > > > > >> some
> > >> > >> > > > > > > > >> > > > > errors
> > >> > >> > > > > > > > >> > > > > > (for example when client try to commit
> > >> > outdated
> > >> > >> > > > > > > transaction).
> > >> > >> > > > > > > > >> But
> > >> > >> > > > > > > > >> > > > > > currently, we don't have data type
> > >> IgniteUuid
> > >> > >> in
> > >> > >> > > thin
> > >> > >> > > > > > client
> > >> > >> > > > > > > > >> > > protocol.
> > >> > >> > > > > > > > >> > > > Do
> > >> > >> > > > > > > > >> > > > > > we need to add it too?
> > >> > >> > > > > > > > >> > > > > > Also, we can pass xid as a string
> just to
> > >> > >> inform
> > >> > >> > the
> > >> > >> > > > > > client
> > >> > >> > > > > > > > and
> > >> > >> > > > > > > > >> do
> > >> > >> > > > > > > > >> > > not
> > >> > >> > > > > > > > >> > > > > pass
> > >> > >> > > > > > > > >> > > > > > it back to the server with
> commit/rollback
> > >> > >> > > operation.
> > >> > >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET thick
> > >> client
> > >> > >> works
> > >> > >> > > > this
> > >> > >> > > > > > way
> > >> > >> > > > > > > as
> > >> > >> > > > > > > > >> far
> > >> > >> > > > > > > > >> > > as I
> > >> > >> > > > > > > > >> > > > > > know).
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > What do you think?
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir
> > >> Ozerov <
> > >> > >> > > > > > > > >> [hidden email]
> > >> > >> > > > > > > > >> > >:
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > > > > We already have transactions
> support in
> > >> > JDBC
> > >> > >> > > driver
> > >> > >> > > > in
> > >> > >> > > > > > TX
> > >> > >> > > > > > > > SQL
> > >> > >> > > > > > > > >> > > branch
> > >> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is
> > >> implemented
> > >> > >> > through
> > >> > >> > > > > > > separate
> > >> > >> > > > > > > > >> > thread,
> > >> > >> > > > > > > > >> > > > > which
> > >> > >> > > > > > > > >> > > > > > > is not that efficient. Ideally we
> need
> > >> to
> > >> > >> finish
> > >> > >> > > > > > > decoupling
> > >> > >> > > > > > > > >> > > > > transactions
> > >> > >> > > > > > > > >> > > > > > > from threads. But alternatively we
> can
> > >> > change
> > >> > >> > the
> > >> > >> > > > > logic
> > >> > >> > > > > > on
> > >> > >> > > > > > > > >> how we
> > >> > >> > > > > > > > >> > > > > assign
> > >> > >> > > > > > > > >> > > > > > > thread ID to specific transaction
> and
> > >> > >> > > "impersonate"
> > >> > >> > > > > thin
> > >> > >> > > > > > > > >> client
> > >> > >> > > > > > > > >> > > > worker
> > >> > >> > > > > > > > >> > > > > > > threads when serving requests from
> > >> multiple
> > >> > >> > users.
> > >> > >> > > > > > > > >> > > > > > >
> > >> > >> > > > > > > > >> > > > > > >
> > >> > >> > > > > > > > >> > > > > > >
> > >> > >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM,
> Denis
> > >> > Magda
> > >> > >> <
> > >> > >> > > > > > > > >> [hidden email]>
> > >> > >> > > > > > > > >> > > > > wrote:
> > >> > >> > > > > > > > >> > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > Here is an original discussion
> with a
> > >> > >> > reference
> > >> > >> > > to
> > >> > >> > > > > the
> > >> > >> > > > > > > > JIRA
> > >> > >> > > > > > > > >> > > ticket:
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > http://apache-ignite-developers.2346864.n4.nabble
> > >> > >> > > > .
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > >
> > >> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > >> > >> > > > > > > > >> > > > > > > > Protocol-td25914.html
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > --
> > >> > >> > > > > > > > >> > > > > > > > Denis
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM,
> > >> Dmitriy
> > >> > >> > > Setrakyan
> > >> > >> > > > <
> > >> > >> > > > > > > > >> > > > > > [hidden email]
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > wrote:
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we
> have a
> > >> > >> design
> > >> > >> > > > > proposal
> > >> > >> > > > > > > for
> > >> > >> > > > > > > > >> > > > transaction
> > >> > >> > > > > > > > >> > > > > > > > support
> > >> > >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind
> taking
> > >> > this
> > >> > >> > > > > initiative
> > >> > >> > > > > > > and
> > >> > >> > > > > > > > >> > > creating
> > >> > >> > > > > > > > >> > > > an
> > >> > >> > > > > > > > >> > > > > > IEP
> > >> > >> > > > > > > > >> > > > > > > > on
> > >> > >> > > > > > > > >> > > > > > > > > Wiki?
> > >> > >> > > > > > > > >> > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > D.
> > >> > >> > > > > > > > >> > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46 AM,
> > >> Dmitriy
> > >> > >> > > > > Govorukhin <
> > >> > >> > > > > > > > >> > > > > > > > > [hidden email]>
> > >> wrote:
> > >> > >> > > > > > > > >> > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> > >> > >> > > > > > > > >> > > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > > I've seen a lot of discussions
> > >> about
> > >> > >> thin
> > >> > >> > > > client
> > >> > >> > > > > > and
> > >> > >> > > > > > > > >> binary
> > >> > >> > > > > > > > >> > > > > > protocol,
> > >> > >> > > > > > > > >> > > > > > > > > but I
> > >> > >> > > > > > > > >> > > > > > > > > > did not hear anything about
> > >> > >> transactions
> > >> > >> > > > > support.
> > >> > >> > > > > > Do
> > >> > >> > > > > > > > we
> > >> > >> > > > > > > > >> > have
> > >> > >> > > > > > > > >> > > > some
> > >> > >> > > > > > > > >> > > > > > > draft
> > >> > >> > > > > > > > >> > > > > > > > > for
> > >> > >> > > > > > > > >> > > > > > > > > > this purpose?
> > >> > >> > > > > > > > >> > > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > > As I understand we have
> several
> > >> > >> problems:
> > >> > >> > > > > > > > >> > > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > >    - thread and transaction
> have
> > >> hard
> > >> > >> > > related
> > >> > >> > > > > (we
> > >> > >> > > > > > > use
> > >> > >> > > > > > > > >> > > > > thread-local
> > >> > >> > > > > > > > >> > > > > > > > > variable
> > >> > >> > > > > > > > >> > > > > > > > > >    and thread name)
> > >> > >> > > > > > > > >> > > > > > > > > >    - we can process only one
> > >> > >> transaction
> > >> > >> > at
> > >> > >> > > > the
> > >> > >> > > > > > same
> > >> > >> > > > > > > > >> time
> > >> > >> > > > > > > > >> > in
> > >> > >> > > > > > > > >> > > > one
> > >> > >> > > > > > > > >> > > > > > > thread
> > >> > >> > > > > > > > >> > > > > > > > > (it
> > >> > >> > > > > > > > >> > > > > > > > > >    mean we need hold thread
> per
> > >> > >> client. If
> > >> > >> > > > > connect
> > >> > >> > > > > > > 100
> > >> > >> > > > > > > > >> thin
> > >> > >> > > > > > > > >> > > > > clients
> > >> > >> > > > > > > > >> > > > > > > to
> > >> > >> > > > > > > > >> > > > > > > > 1
> > >> > >> > > > > > > > >> > > > > > > > > >    server node, then need to
> hold
> > >> 100
> > >> > >> > thread
> > >> > >> > > > on
> > >> > >> > > > > > the
> > >> > >> > > > > > > > >> server
> > >> > >> > > > > > > > >> > > > side)
> > >> > >> > > > > > > > >> > > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > > > Let's discuss how we can
> implement
> > >> > >> > > > transactions
> > >> > >> > > > > > for
> > >> > >> > > > > > > > the
> > >> > >> > > > > > > > >> > thin
> > >> > >> > > > > > > > >> > > > > > client.
> > >> > >> > > > > > > > >> > > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > > >
> > >> > >> > > > > > > > >> > > > > > > >
> > >> > >> > > > > > > > >> > > > > > >
> > >> > >> > > > > > > > >> > > > > >
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > > > --
> > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > >> > >> > > > > > > > >> > > > > GridGain Systems
> > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > >> > >> > > > > > > > >> > > > >
> > >> > >> > > > > > > > >> > > >
> > >> > >> > > > > > > > >> > >
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >> > --
> > >> > >> > > > > > > > >> > Sergey Kozlov
> > >> > >> > > > > > > > >> > GridGain Systems
> > >> > >> > > > > > > > >> > www.gridgain.com
> > >> > >> > > > > > > > >> >
> > >> > >> > > > > > > > >>
> > >> > >> > > > > > > > >
> > >> > >> > > > > > > >
> > >> > >> > > > > > >
> > >> > >> > > > > >
> > >> > >> > > > >
> > >> > >> > > >
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> >
> > >>
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>
>

[Igor Sapego-2]

Hi,

I had a look at IEP and have several comments:

1. Why would one want to use to use server's default values for Concurrency
or Isolation?
I believe, client should have its own defaults which should be explicitly
documented, so that
behaviour of transactions will not depend on the server node it was routed
to. The same goes
for timeout.

2. Not sure about transaction ID represented by int. Why not to use
IgniteUuid? It should simplify
server code. Also it may help with monitoring/debugging if thin clients and
server nodes use the
same identifier for transactions. It does not seem as a big overhead to me
either.

3. Maybe it makes sense to add "In transaction" boolean flag to cache
operation request header
to avoid bloating message size in non-affected scenarios.

Best Regards,
Igor


On Mon, May 13, 2019 at 1:58 PM Alex Plehanov <[hidden email]>
wrote:

> Hi, Ivan.
>
> Thanks for your comments.
>
> 1. Transaction id in thin client protocol it's just a tx counter for the
> current connection. It's not related to GridCacheVersion. If we want to
> know GridCacheVersion on the client side, I think we should introduce a new
> type of operation (for example OP_TX_INFO).
> 2. Error handling is already provided by thin client protocol, even in case
> of empty response. Of course, the client will know if there is a failure
> occurred during OP_TX_END operation.
> 3. AFAIK some of thin client implementations already send requests and
> process responses in an async way (.NET for example). As for java thin
> client, in the current implementation channel is locked exclusively before
> request send and until the response is processed. I have some ideas about
> how to fix this (split send/receive process into two different parts and
> acquire locks for this parts separately or create futures on request sent
> and complete it after processing the response in a dedicated thread), I've
> created ticket [1] for this issue and will try to implement prototype in a
> couple of days.
>
> About suspend/resume, yes, on server-side we should resume tx before each
> transactional cache operation and suspend the tx after the operation. In my
> opinion, suspend/resume approach have several advantages over approach with
> explicit tx id argument:
> - Introducing explicit tx id argument for cache operations leads to a
> significant API change
> - It's not clear how to use it together with current (tx-per-thread)
> approach (for example, what if a thread is already held transaction and
> someone call cache operation with explicit tx id?)
> - Suspend/resume feature will also be useful for thick clients
> - Suspend/resume functionality is already partially implemented (for
> optimistic transactions only)
>
> [1] https://issues.apache.org/jira/browse/IGNITE-11685
>
> пт, 3 мая 2019 г. в 08:10, Павлухин Иван <[hidden email]>:
>
> > Hi Alex,
> >
> > I went through IEP [1] and I have a couple of questions:
> > 1. What is going to be used as transaction id? In a described protocol
> > I see an int field for it. Should not it be GridCacheVersion
> > corresponding to IgniteInternalTx#xidVersion?
> > 2. OP_TX_END message assumes an empty response, but I think that
> > errors during tx finish are possible and should be returned in a
> > response.
> > 3. In IEP it is stated that async processing of lock operations should
> > be introduced on a client side to enable concurrent operations from
> > different client threads. Do you have an idea how to achieve it?
> >
> > Also, a bit about a suspend/resume trait. I tried to think about it
> > leaving away an existing transactions implementation in Ignite. As I
> > understood we are going to resume a tx before each cache operation in
> > the tx and resume the tx after the operation. All this to make an
> > executing thread available for other operations (e.g. in other txs).
> > From the first glance it seems like an inversed logic. A
> > straightforward way is to execute a cache operation within a
> > particular transaction defined as an explicit tx id argument (e.g.
> > cache.put(key, value, txid)). Can we do so?
> >
> > And leaving for now thin client API. I cannot say that one proposed in
> > IEP is good or bad. I can only say that it ressembles current thick
> > client API. And perhaps it should not. I think that we should consider
> > similar APIs provided by other vendors and keep in mind that we have a
> > bunch of client implementations for different languages. I suppose
> > that we can return to it a little bit later. And I hope that we will
> > do it.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> >
> > вт, 30 апр. 2019 г. в 13:24, Alex Plehanov <[hidden email]>:
> > >
> > > Hello, Igniters!
> > >
> > > I've update IEP [1] and implement PoC according to new approach
> (multiple
> > > concurrent transactions per connection).
> > > But to move forward another feature need to be implemented:
> > suspend/resume
> > > for pessimistic transactions (IGNITE-5714 [2]). Implementation of
> > > suspend/resume is ready now and ticket in 'Patch available' status. Can
> > any
> > > transactions expert help with review of IGNITE-5714?
> > >
> > > [1]:
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > [2]: https://issues.apache.org/jira/browse/IGNITE-5714
> > >
> > > чт, 4 апр. 2019 г. в 11:32, Alex Plehanov <[hidden email]>:
> > >
> > > > Vladimir,
> > > >
> > > > Ok, then I will rewrite IEP in the near future.
> > > >
> > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <[hidden email]>:
> > > >
> > > >> Hi Alex,
> > > >>
> > > >> I think we should be able to handle many transactions through a
> single
> > > >> connection. This will make our protocol and client implementations
> > much
> > > >> more efficient, and simplicity from developer's perspective is not
> our
> > > >> goal. Consider normal nodes. We have server nodes and client nodes.
> > You
> > > >> may
> > > >> span whatever number of transactions you need, but all of them are
> > > >> coordinated through a single connection. The same should be
> > applicable to
> > > >> thin clients. Protocol is already designed to handle this, as we
> pass
> > > >> unique operation ID in order to distinguish one operation from
> > another. It
> > > >> is true, though, that we will have to introduce a kind of "session"
> > > >> concept, and pass additional identifier along with cache operations,
> > but
> > > >> this doesn't sound like a problem to me.
> > > >>
> > > >> And provided that currently server-side transactions are bound to
> > threads
> > > >> artificially, I would say that the first step in implementation of
> > > >> transactions on thin clients should be decoupling server-side
> > transactions
> > > >> from threads. Without this we will have very inefficient
> > implementation,
> > > >> when every new client transaction have to spawn a new thread. This
> is
> > slow
> > > >> and introduces high memory pressure on a cluster node. We already
> work
> > > >> this
> > > >> way for MVCC transactions which are spawned from JDBC driver, and
> > believe
> > > >> me, we do not want to replicated this bad practice to other clients
> > :-)
> > > >>
> > > >> Vladimir.
> > > >>
> > > >> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <
> > [hidden email]>
> > > >> wrote:
> > > >>
> > > >> > Guys, so, do we need multiple concurrent transactions per
> > connection?
> > > >> >
> > > >> > There are pros and cons for each approach. Difference between
> > > >> approaches:
> > > >> >
> > > >> > One transaction at a time per connection:
> > > >> >  - This approach is used in RDBMS world and users got used to it
> > > >> >  - To use transactions concurrently users need to use different
> > > >> connections
> > > >> > and get these connections via something like a connection pool
> > > >> >  - Easy to implement (in fact, PoC is already done)
> > > >> >
> > > >> > Multiple concurrent transactions per connection:
> > > >> >  - At least for java thin client, we can implement transaction per
> > > >> thread
> > > >> > approach as implemented now for the thick client (perhaps other
> thin
> > > >> > clients can implement the same abstraction)
> > > >> >  - There is also protocol change for all cache operations needed
> (to
> > > >> bind
> > > >> > cache operation to the transaction)
> > > >> >  - Significant changes to all implemented clients are needed
> > > >> >  - Implementation on the server side is more complex
> > > >> >
> > > >> > What do you think?
> > > >> >
> > > >> >
> > > >> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <
> [hidden email]
> > >:
> > > >> >
> > > >> > > Ilya,
> > > >> > >
> > > >> > > > We should be able to multiplex several transactions using a
> > single
> > > >> > > Client connection.
> > > >> > > In this case, we should significantly change cache operations
> > syntax
> > > >> (for
> > > >> > > each implemented client), to bind each operation to the
> > transaction.
> > > >> > >
> > > >> > > > I want to also ask if "Number of entries participating in
> > > >> transaction
> > > >> > > (may be approximate). 0 - default value." is needed.
> > > >> > > I've tried to minimize API changes between thick and thin client
> > to
> > > >> > > simplify move from one to another. It's the only reason. But I
> > agree
> > > >> with
> > > >> > > you, the parameter is not very useful.
> > > >> > >
> > > >> > >
> > > >> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <
> > > >> [hidden email]>:
> > > >> > >
> > > >> > >> Hello!
> > > >> > >>
> > > >> > >> Pavel, I agree with you thorougly. We should be able to
> multiplex
> > > >> > several
> > > >> > >> transactions using a single Client connection. This means
> adding
> > > >> > >> Transaction id parameter to every affected cache operation /
> SQL
> > > >> > statement
> > > >> > >> (if applicable) to make sure we do cache operations on relevant
> > > >> > >> transaction.
> > > >> > >>
> > > >> > >> This is how other things work in Ignite, such as communication.
> > We do
> > > >> > not
> > > >> > >> open dozens of connections, we multiplex operations
> > asynchronously
> > > >> > through
> > > >> > >> a single connection.
> > > >> > >>
> > > >> > >> I think that trying to pool Ignite connections will be highly
> > > >> > >> inconvenient,
> > > >> > >> since there is no existing infrastructure for such pooling
> (like
> > > >> there
> > > >> > >> exists for JDBC).
> > > >> > >>
> > > >> > >> I want to also ask if "Number of entries participating in
> > transaction
> > > >> > (may
> > > >> > >> be approximate). 0 - default value." is needed. Does it
> actually
> > do
> > > >> > >> anything in our tx protocol? Users of existing APIs are already
> > > >> confused
> > > >> > >> by
> > > >> > >> this parameter, if we could get rid of it in thin client
> > protocol it
> > > >> > would
> > > >> > >> be nice clean-up.
> > > >> > >>
> > > >> > >> Regards,
> > > >> > >> --
> > > >> > >> Ilya Kasnacheev
> > > >> > >>
> > > >> > >>
> > > >> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <
> [hidden email]
> > >:
> > > >> > >>
> > > >> > >> > Alex,
> > > >> > >> >
> > > >> > >> > > now we can only support one active transaction per
> connection
> > > >> > >> >
> > > >> > >> > I totally understand server-side and protocol limitations
> that
> > are
> > > >> > >> causing
> > > >> > >> > this.
> > > >> > >> > But I have no idea how to support this in .NET Thin Client,
> for
> > > >> > example.
> > > >> > >> >
> > > >> > >> > It is thread-safe and can handle multiple async operations in
> > > >> > parallel.
> > > >> > >> > But with TX support we have to somehow switch to
> > single-threaded
> > > >> mode
> > > >> > to
> > > >> > >> > avoid unexpected effects.
> > > >> > >> >
> > > >> > >> > Any ideas?
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <
> > > >> [hidden email]
> > > >> > >
> > > >> > >> > wrote:
> > > >> > >> >
> > > >> > >> > > Dmitriy, thank you!
> > > >> > >> > >
> > > >> > >> > > Guys, I've created the IEP [1] on wiki, please have a look.
> > > >> > >> > >
> > > >> > >> > > [1]
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> >
> > > >>
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <
> > [hidden email]
> > > >> >:
> > > >> > >> > >
> > > >> > >> > > > Hi,
> > > >> > >> > > >
> > > >> > >> > > > I've added permissions to account plehanov.alex
> > > >> > >> > > >
> > > >> > >> > > > Recently Infra integrated Apache LDAP with confluence, so
> > it is
> > > >> > >> > possible
> > > >> > >> > > to
> > > >> > >> > > > login using Apache credentials. Probably we can ask infra
> > if
> > > >> extra
> > > >> > >> > > > permissions to edit pages should be added for committers.
> > > >> > >> > > >
> > > >> > >> > > > Sincerely,
> > > >> > >> > > > Dmitriy Pavlov
> > > >> > >> > > >
> > > >> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
> > > >> > [hidden email]
> > > >> > >> >:
> > > >> > >> > > >
> > > >> > >> > > > > Vladimir,
> > > >> > >> > > > >
> > > >> > >> > > > > About current tx: ok, then we don't need tx() method in
> > the
> > > >> > >> interface
> > > >> > >> > > at
> > > >> > >> > > > > all (the same cached transaction info user can store by
> > > >> > himself).
> > > >> > >> > > > >
> > > >> > >> > > > > About decoupling transactions from threads on the
> server
> > > >> side:
> > > >> > for
> > > >> > >> > now,
> > > >> > >> > > > we
> > > >> > >> > > > > can start with thread-per-connection approach (we only
> > can
> > > >> > support
> > > >> > >> > one
> > > >> > >> > > > > active transaction per connection, see below, so we
> need
> > one
> > > >> > >> > additional
> > > >> > >> > > > > dedicated thread for each connection with active
> > > >> transaction),
> > > >> > and
> > > >> > >> > > later
> > > >> > >> > > > > change server-side internals to process client
> > transactions
> > > >> in
> > > >> > any
> > > >> > >> > > server
> > > >> > >> > > > > thread (not dedicated to this connection). This change
> > will
> > > >> not
> > > >> > >> > affect
> > > >> > >> > > > the
> > > >> > >> > > > > thin client protocol, it only affects the server side.
> > > >> > >> > > > > In any case, we can't support concurrent transactions
> per
> > > >> > >> connection
> > > >> > >> > on
> > > >> > >> > > > > the client side without fundamental changes to the
> > current
> > > >> > >> protocol
> > > >> > >> > > > (cache
> > > >> > >> > > > > operation doesn't bound to transaction or thread and
> the
> > > >> server
> > > >> > >> > doesn't
> > > >> > >> > > > > know which thread on the client side do this cache
> > > >> operation).
> > > >> > In
> > > >> > >> my
> > > >> > >> > > > > opinion, if a user wants to use concurrent
> transactions,
> > he
> > > >> must
> > > >> > >> use
> > > >> > >> > > > > different connections from a connection pool.
> > > >> > >> > > > >
> > > >> > >> > > > > About semantics of suspend/resume on the client-side:
> > it's
> > > >> > >> absolutely
> > > >> > >> > > > > different than server-side semantics (we don't need to
> do
> > > >> > >> > > suspend/resume
> > > >> > >> > > > to
> > > >> > >> > > > > pass transaction between threads on the client-side),
> but
> > > >> can't
> > > >> > be
> > > >> > >> > > > > implemented efficiently without implemented
> > suspend/resume on
> > > >> > >> > > > server-side.
> > > >> > >> > > > >
> > > >> > >> > > > > Can anyone give me permissions to create IEP on Apache
> > wiki?
> > > >> > >> > > > >
> > > >> > >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
> > > >> > >> [hidden email]>:
> > > >> > >> > > > >
> > > >> > >> > > > > > Hi Alex,
> > > >> > >> > > > > >
> > > >> > >> > > > > > My comments was only about the protocol. Getting
> > current
> > > >> info
> > > >> > >> about
> > > >> > >> > > > > > transaction should be handled by the client itself.
> It
> > is
> > > >> not
> > > >> > >> > > protocl's
> > > >> > >> > > > > > concern. Same about other APIs and behavior in case
> > another
> > > >> > >> > > transaction
> > > >> > >> > > > > is
> > > >> > >> > > > > > attempted from the same thread.
> > > >> > >> > > > > >
> > > >> > >> > > > > > Putting protocol aside, transaction support is
> > complicated
> > > >> > >> matter.
> > > >> > >> > I
> > > >> > >> > > > > would
> > > >> > >> > > > > > propose to route through IEP and wide community
> > > >> discussion. We
> > > >> > >> need
> > > >> > >> > > to
> > > >> > >> > > > > > review API and semantics very carefully, taking
> > > >> SUSPEND/RESUME
> > > >> > >> in
> > > >> > >> > > > count.
> > > >> > >> > > > > > Also I do not see how we support client transactions
> > > >> > efficiently
> > > >> > >> > > > without
> > > >> > >> > > > > > decoupling transactions from threads on the server
> side
> > > >> first.
> > > >> > >> > > Because
> > > >> > >> > > > > > without it you will need a dedicated server thread
> for
> > > >> every
> > > >> > >> > client's
> > > >> > >> > > > > > transaction which is slow and may even crash the
> > server.
> > > >> > >> > > > > >
> > > >> > >> > > > > > Vladimir.
> > > >> > >> > > > > >
> > > >> > >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > > >> > >> > > > [hidden email]>
> > > >> > >> > > > > > wrote:
> > > >> > >> > > > > >
> > > >> > >> > > > > > > Vladimir, what if we want to get current
> transaction
> > info
> > > >> > >> (tx()
> > > >> > >> > > > > method)?
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Does close() method mapped to TX_END(rollback)?
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > For example, this code:
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > try(tx = txStart()) {
> > > >> > >> > > > > > >     tx.commit();
> > > >> > >> > > > > > > }
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Will produce:
> > > >> > >> > > > > > > TX_START
> > > >> > >> > > > > > > TX_END(commit)
> > > >> > >> > > > > > > TX_END(rollback)
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > Am I understand you right?
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > About xid. There is yet another proposal. Use some
> > unique
> > > >> > per
> > > >> > >> > > > > connection
> > > >> > >> > > > > > id
> > > >> > >> > > > > > > (integer, simple counter) for identifying the
> > > >> transaction on
> > > >> > >> > > > > > > commit/rollback message. The client gets this id
> > from the
> > > >> > >> server
> > > >> > >> > > with
> > > >> > >> > > > > > > transaction info and sends it back to the server
> when
> > > >> trying
> > > >> > >> to
> > > >> > >> > > > > > > commit/rollback transaction. This id is not shown
> to
> > > >> users.
> > > >> > >> But
> > > >> > >> > > also
> > > >> > >> > > > we
> > > >> > >> > > > > > can
> > > >> > >> > > > > > > pass from server to client real transaction id
> (xid)
> > with
> > > >> > >> > > transaction
> > > >> > >> > > > > > info
> > > >> > >> > > > > > > for diagnostic purposes.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > And one more question: what should we do if the
> > client
> > > >> > starts
> > > >> > >> a
> > > >> > >> > new
> > > >> > >> > > > > > > transaction without ending the old one? Should we
> > end the
> > > >> > old
> > > >> > >> > > > > transaction
> > > >> > >> > > > > > > implicitly (rollback) or throw an exception to the
> > > >> client?
> > > >> > In
> > > >> > >> my
> > > >> > >> > > > > opinion,
> > > >> > >> > > > > > > the first option is better. For example, if we got
> a
> > > >> > >> previously
> > > >> > >> > > used
> > > >> > >> > > > > > > connection from the connection pool, we should not
> > worry
> > > >> > about
> > > >> > >> > any
> > > >> > >> > > > > > > uncompleted transaction started by the previous
> user
> > of
> > > >> this
> > > >> > >> > > > > connection.
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> > > >> > >> > [hidden email]
> > > >> > >> > > >:
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not
> > support
> > > >> > them
> > > >> > >> > yet,
> > > >> > >> > > > and
> > > >> > >> > > > > > > adding
> > > >> > >> > > > > > > > them in future should not conflict with simple
> > > >> START/END
> > > >> > >> > > > > > infrastructure.
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov
> <
> > > >> > >> > > > > [hidden email]
> > > >> > >> > > > > > >
> > > >> > >> > > > > > > > wrote:
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > > Hi Alex,
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it
> be
> > > >> enough
> > > >> > to
> > > >> > >> > have
> > > >> > >> > > > > only
> > > >> > >> > > > > > > two?
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > START - accepts optional parameters, returns
> > > >> transaction
> > > >> > >> info
> > > >> > >> > > > > > > > > END - provides commit flag, returns void
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > Vladimir.
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex Plehanov <
> > > >> > >> > > > > > [hidden email]
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > > > > wrote:
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > > >> Sergey, yes, the close is something like
> silent
> > > >> > rollback.
> > > >> > >> > But
> > > >> > >> > > we
> > > >> > >> > > > > can
> > > >> > >> > > > > > > > >> also implement this on the client side, just
> > using
> > > >> > >> rollback
> > > >> > >> > > and
> > > >> > >> > > > > > > ignoring
> > > >> > >> > > > > > > > >> errors in the response.
> > > >> > >> > > > > > > > >>
> > > >> > >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> > > >> > >> > > > [hidden email]
> > > >> > >> > > > > >:
> > > >> > >> > > > > > > > >>
> > > >> > >> > > > > > > > >> > Nikolay
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > Am I correctly understand you points:
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> >    - close: rollback
> > > >> > >> > > > > > > > >> >    - commit, close: do nothing
> > > >> > >> > > > > > > > >> >    - rollback, close: do what? (I suppose
> > nothing)
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > Also you assume that after commit/rollback
> we
> > may
> > > >> > need
> > > >> > >> to
> > > >> > >> > > free
> > > >> > >> > > > > > some
> > > >> > >> > > > > > > > >> > resources on server node(s)or just do on
> > client
> > > >> > started
> > > >> > >> > TX?
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex
> > Plehanov <
> > > >> > >> > > > > > > > [hidden email]
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > wrote:
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > > Sergey, we have the close() method in the
> > thick
> > > >> > >> client,
> > > >> > >> > > it's
> > > >> > >> > > > > > > > behavior
> > > >> > >> > > > > > > > >> is
> > > >> > >> > > > > > > > >> > > slightly different than rollback() method
> > (it
> > > >> > should
> > > >> > >> > > > rollback
> > > >> > >> > > > > if
> > > >> > >> > > > > > > the
> > > >> > >> > > > > > > > >> > > transaction is not committed and do
> nothing
> > if
> > > >> the
> > > >> > >> > > > transaction
> > > >> > >> > > > > > is
> > > >> > >> > > > > > > > >> already
> > > >> > >> > > > > > > > >> > > committed). I think we should support
> > > >> > >> try-with-resource
> > > >> > >> > > > > > semantics
> > > >> > >> > > > > > > in
> > > >> > >> > > > > > > > >> the
> > > >> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be useful
> > here.
> > > >> > >> > > > > > > > >> > >
> > > >> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet
> for
> > > >> > >> pessimistic
> > > >> > >> > > > > > > > transactions.
> > > >> > >> > > > > > > > >> > Also,
> > > >> > >> > > > > > > > >> > > the main goal of suspend/resume operations
> > is to
> > > >> > >> support
> > > >> > >> > > > > > > transaction
> > > >> > >> > > > > > > > >> > > passing between threads. In the thin
> > client, the
> > > >> > >> > > transaction
> > > >> > >> > > > > is
> > > >> > >> > > > > > > > bound
> > > >> > >> > > > > > > > >> to
> > > >> > >> > > > > > > > >> > > the client connection, not client thread.
> I
> > > >> think
> > > >> > >> > passing
> > > >> > >> > > a
> > > >> > >> > > > > > > > >> transaction
> > > >> > >> > > > > > > > >> > > between different client connections is
> not
> > a
> > > >> very
> > > >> > >> > useful
> > > >> > >> > > > > case.
> > > >> > >> > > > > > > > >> > >
> > > >> > >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay
> > Izhikov <
> > > >> > >> > > > > > [hidden email]
> > > >> > >> > > > > > > >:
> > > >> > >> > > > > > > > >> > >
> > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > operations.
> > > >> > >> > > > > > > > >> > > > I think we should support them
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey
> Kozlov
> > <
> > > >> > >> > > > > > [hidden email]
> > > >> > >> > > > > > > >:
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > > Hi
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > > Looks like I missed something but why
> we
> > > >> need
> > > >> > >> > > > OP_TX_CLOSE
> > > >> > >> > > > > > > > >> operation?
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > > Also I suggest to reserve a code for
> > > >> SAVEPOINT
> > > >> > >> > > operation
> > > >> > >> > > > > > which
> > > >> > >> > > > > > > > >> very
> > > >> > >> > > > > > > > >> > > > useful
> > > >> > >> > > > > > > > >> > > > > to understand where transaction has
> been
> > > >> rolled
> > > >> > >> back
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex
> > > >> Plehanov <
> > > >> > >> > > > > > > > >> > [hidden email]
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > > > > wrote:
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > > > Hello Igniters!
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > I want to pick up the ticket
> > IGNITE-7369
> > > >> and
> > > >> > >> add
> > > >> > >> > > > > > > transactions
> > > >> > >> > > > > > > > >> > support
> > > >> > >> > > > > > > > >> > > > to
> > > >> > >> > > > > > > > >> > > > > > our thin client implementation.
> > > >> > >> > > > > > > > >> > > > > > I've looked at our current
> > implementation
> > > >> and
> > > >> > >> have
> > > >> > >> > > > some
> > > >> > >> > > > > > > > >> proposals
> > > >> > >> > > > > > > > >> > to
> > > >> > >> > > > > > > > >> > > > > > support transactions:
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > Add new operations to thin client
> > > >> protocol:
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current
> > > >> transaction
> > > >> > >> for
> > > >> > >> > > > client
> > > >> > >> > > > > > > > >> connection
> > > >> > >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
> > > >> > transaction
> > > >> > >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit
> > transaction
> > > >> > >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
> > > >> > transaction
> > > >> > >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close
> > transaction
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > From the client side (java) new
> > interfaces
> > > >> > >> will be
> > > >> > >> > > > > added:
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > public interface ClientTransactions
> {
> > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > txStart();
> > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > > >> > >> > > > > > txStart(TransactionConcurrency
> > > >> > >> > > > > > > > >> > > > concurrency,
> > > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation);
> > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > > >> > >> > > > > > txStart(TransactionConcurrency
> > > >> > >> > > > > > > > >> > > > concurrency,
> > > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation, long
> > > >> timeout,
> > > >> > >> int
> > > >> > >> > > > > txSize);
> > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction tx();
> //
> > Get
> > > >> > >> current
> > > >> > >> > > > > > connection
> > > >> > >> > > > > > > > >> > > > transaction
> > > >> > >> > > > > > > > >> > > > > >     public ClientTransactions
> > > >> > withLabel(String
> > > >> > >> > lb);
> > > >> > >> > > > > > > > >> > > > > > }
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > public interface ClientTransaction
> > extends
> > > >> > >> > > > > AutoCloseable {
> > > >> > >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do
> we
> > need
> > > >> > it?
> > > >> > >> > > > > > > > >> > > > > >     public TransactionIsolation
> > > >> isolation();
> > > >> > >> > > > > > > > >> > > > > >     public TransactionConcurrency
> > > >> > >> concurrency();
> > > >> > >> > > > > > > > >> > > > > >     public long timeout();
> > > >> > >> > > > > > > > >> > > > > >     public String label();
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > >     public void commit();
> > > >> > >> > > > > > > > >> > > > > >     public void rollback();
> > > >> > >> > > > > > > > >> > > > > >     public void close();
> > > >> > >> > > > > > > > >> > > > > > }
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > From the server side, I think as a
> > first
> > > >> step
> > > >> > >> > (while
> > > >> > >> > > > > > > > >> transactions
> > > >> > >> > > > > > > > >> > > > > > suspend/resume is not fully
> > implemented)
> > > >> we
> > > >> > can
> > > >> > >> > use
> > > >> > >> > > > the
> > > >> > >> > > > > > same
> > > >> > >> > > > > > > > >> > approach
> > > >> > >> > > > > > > > >> > > > as
> > > >> > >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> > > >> > >> > > > ClientRequestHandler
> > > >> > >> > > > > > and
> > > >> > >> > > > > > > > >> process
> > > >> > >> > > > > > > > >> > > > > > requests by this worker if the
> > > >> transaction is
> > > >> > >> > > started
> > > >> > >> > > > > > > > >> explicitly.
> > > >> > >> > > > > > > > >> > > > > > ClientRequestHandler is bound to
> > client
> > > >> > >> > connection,
> > > >> > >> > > so
> > > >> > >> > > > > > there
> > > >> > >> > > > > > > > >> will
> > > >> > >> > > > > > > > >> > be
> > > >> > >> > > > > > > > >> > > > 1:1
> > > >> > >> > > > > > > > >> > > > > > relation between client connection
> and
> > > >> > thread,
> > > >> > >> > which
> > > >> > >> > > > > > process
> > > >> > >> > > > > > > > >> > > operations
> > > >> > >> > > > > > > > >> > > > > in
> > > >> > >> > > > > > > > >> > > > > > a transaction.
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > Also, there is a couple of issues I
> > want
> > > >> to
> > > >> > >> > discuss:
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > We have overloaded method txStart
> > with a
> > > >> > >> different
> > > >> > >> > > set
> > > >> > >> > > > > of
> > > >> > >> > > > > > > > >> > arguments.
> > > >> > >> > > > > > > > >> > > > Some
> > > >> > >> > > > > > > > >> > > > > > of the arguments may be missing. To
> > pass
> > > >> > >> arguments
> > > >> > >> > > > with
> > > >> > >> > > > > > > > >> OP_TX_START
> > > >> > >> > > > > > > > >> > > > > > operation we have the next options:
> > > >> > >> > > > > > > > >> > > > > >  * Serialize full set of arguments
> > and use
> > > >> > some
> > > >> > >> > > value
> > > >> > >> > > > > for
> > > >> > >> > > > > > > > >> missing
> > > >> > >> > > > > > > > >> > > > > > arguments. For example -1 for
> int/long
> > > >> types
> > > >> > >> and
> > > >> > >> > > null
> > > >> > >> > > > > for
> > > >> > >> > > > > > > > string
> > > >> > >> > > > > > > > >> > > type.
> > > >> > >> > > > > > > > >> > > > We
> > > >> > >> > > > > > > > >> > > > > > can't use 0 for int/long types
> since 0
> > > >> it's a
> > > >> > >> > valid
> > > >> > >> > > > > value
> > > >> > >> > > > > > > for
> > > >> > >> > > > > > > > >> > > > > concurrency,
> > > >> > >> > > > > > > > >> > > > > > isolation and timeout arguments.
> > > >> > >> > > > > > > > >> > > > > >  * Serialize arguments as a
> > collection of
> > > >> > >> > > > property-value
> > > >> > >> > > > > > > pairs
> > > >> > >> > > > > > > > >> > (like
> > > >> > >> > > > > > > > >> > > > it's
> > > >> > >> > > > > > > > >> > > > > > implemented now for
> > CacheConfiguration).
> > > >> In
> > > >> > >> this
> > > >> > >> > > case
> > > >> > >> > > > > only
> > > >> > >> > > > > > > > >> > explicitly
> > > >> > >> > > > > > > > >> > > > > > provided arguments will be
> serialized.
> > > >> > >> > > > > > > > >> > > > > > Which way is better? The simplest
> > > >> solution is
> > > >> > >> to
> > > >> > >> > use
> > > >> > >> > > > the
> > > >> > >> > > > > > > first
> > > >> > >> > > > > > > > >> > option
> > > >> > >> > > > > > > > >> > > > > and I
> > > >> > >> > > > > > > > >> > > > > > want to use it if there were no
> > > >> objections.
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > Do we need transaction id (xid) on
> the
> > > >> client
> > > >> > >> > side?
> > > >> > >> > > > > > > > >> > > > > > If yes, we can pass xid along with
> > > >> > >> OP_TX_COMMIT,
> > > >> > >> > > > > > > > OP_TX_ROLLBACK,
> > > >> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the
> > server
> > > >> and
> > > >> > >> do
> > > >> > >> > > > > > additional
> > > >> > >> > > > > > > > >> check
> > > >> > >> > > > > > > > >> > on
> > > >> > >> > > > > > > > >> > > > the
> > > >> > >> > > > > > > > >> > > > > > server side (current transaction id
> > for
> > > >> > >> connection
> > > >> > >> > > ==
> > > >> > >> > > > > > > > >> transaction
> > > >> > >> > > > > > > > >> > id
> > > >> > >> > > > > > > > >> > > > > passed
> > > >> > >> > > > > > > > >> > > > > > from client side). This, perhaps,
> will
> > > >> > protect
> > > >> > >> > > clients
> > > >> > >> > > > > > > against
> > > >> > >> > > > > > > > >> some
> > > >> > >> > > > > > > > >> > > > > errors
> > > >> > >> > > > > > > > >> > > > > > (for example when client try to
> commit
> > > >> > outdated
> > > >> > >> > > > > > > transaction).
> > > >> > >> > > > > > > > >> But
> > > >> > >> > > > > > > > >> > > > > > currently, we don't have data type
> > > >> IgniteUuid
> > > >> > >> in
> > > >> > >> > > thin
> > > >> > >> > > > > > client
> > > >> > >> > > > > > > > >> > > protocol.
> > > >> > >> > > > > > > > >> > > > Do
> > > >> > >> > > > > > > > >> > > > > > we need to add it too?
> > > >> > >> > > > > > > > >> > > > > > Also, we can pass xid as a string
> > just to
> > > >> > >> inform
> > > >> > >> > the
> > > >> > >> > > > > > client
> > > >> > >> > > > > > > > and
> > > >> > >> > > > > > > > >> do
> > > >> > >> > > > > > > > >> > > not
> > > >> > >> > > > > > > > >> > > > > pass
> > > >> > >> > > > > > > > >> > > > > > it back to the server with
> > commit/rollback
> > > >> > >> > > operation.
> > > >> > >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET
> thick
> > > >> client
> > > >> > >> works
> > > >> > >> > > > this
> > > >> > >> > > > > > way
> > > >> > >> > > > > > > as
> > > >> > >> > > > > > > > >> far
> > > >> > >> > > > > > > > >> > > as I
> > > >> > >> > > > > > > > >> > > > > > know).
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > What do you think?
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22, Vladimir
> > > >> Ozerov <
> > > >> > >> > > > > > > > >> [hidden email]
> > > >> > >> > > > > > > > >> > >:
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > > > > We already have transactions
> > support in
> > > >> > JDBC
> > > >> > >> > > driver
> > > >> > >> > > > in
> > > >> > >> > > > > > TX
> > > >> > >> > > > > > > > SQL
> > > >> > >> > > > > > > > >> > > branch
> > > >> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is
> > > >> implemented
> > > >> > >> > through
> > > >> > >> > > > > > > separate
> > > >> > >> > > > > > > > >> > thread,
> > > >> > >> > > > > > > > >> > > > > which
> > > >> > >> > > > > > > > >> > > > > > > is not that efficient. Ideally we
> > need
> > > >> to
> > > >> > >> finish
> > > >> > >> > > > > > > decoupling
> > > >> > >> > > > > > > > >> > > > > transactions
> > > >> > >> > > > > > > > >> > > > > > > from threads. But alternatively we
> > can
> > > >> > change
> > > >> > >> > the
> > > >> > >> > > > > logic
> > > >> > >> > > > > > on
> > > >> > >> > > > > > > > >> how we
> > > >> > >> > > > > > > > >> > > > > assign
> > > >> > >> > > > > > > > >> > > > > > > thread ID to specific transaction
> > and
> > > >> > >> > > "impersonate"
> > > >> > >> > > > > thin
> > > >> > >> > > > > > > > >> client
> > > >> > >> > > > > > > > >> > > > worker
> > > >> > >> > > > > > > > >> > > > > > > threads when serving requests from
> > > >> multiple
> > > >> > >> > users.
> > > >> > >> > > > > > > > >> > > > > > >
> > > >> > >> > > > > > > > >> > > > > > >
> > > >> > >> > > > > > > > >> > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM,
> > Denis
> > > >> > Magda
> > > >> > >> <
> > > >> > >> > > > > > > > >> [hidden email]>
> > > >> > >> > > > > > > > >> > > > > wrote:
> > > >> > >> > > > > > > > >> > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > Here is an original discussion
> > with a
> > > >> > >> > reference
> > > >> > >> > > to
> > > >> > >> > > > > the
> > > >> > >> > > > > > > > JIRA
> > > >> > >> > > > > > > > >> > > ticket:
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > http://apache-ignite-developers.2346864.n4.nabble
> > > >> > >> > > > .
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > >
> > > >> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > > >> > >> > > > > > > > >> > > > > > > > Protocol-td25914.html
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > --
> > > >> > >> > > > > > > > >> > > > > > > > Denis
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18 AM,
> > > >> Dmitriy
> > > >> > >> > > Setrakyan
> > > >> > >> > > > <
> > > >> > >> > > > > > > > >> > > > > > [hidden email]
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > wrote:
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we
> > have a
> > > >> > >> design
> > > >> > >> > > > > proposal
> > > >> > >> > > > > > > for
> > > >> > >> > > > > > > > >> > > > transaction
> > > >> > >> > > > > > > > >> > > > > > > > support
> > > >> > >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind
> > taking
> > > >> > this
> > > >> > >> > > > > initiative
> > > >> > >> > > > > > > and
> > > >> > >> > > > > > > > >> > > creating
> > > >> > >> > > > > > > > >> > > > an
> > > >> > >> > > > > > > > >> > > > > > IEP
> > > >> > >> > > > > > > > >> > > > > > > > on
> > > >> > >> > > > > > > > >> > > > > > > > > Wiki?
> > > >> > >> > > > > > > > >> > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > D.
> > > >> > >> > > > > > > > >> > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46
> AM,
> > > >> Dmitriy
> > > >> > >> > > > > Govorukhin <
> > > >> > >> > > > > > > > >> > > > > > > > > [hidden email]>
> > > >> wrote:
> > > >> > >> > > > > > > > >> > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> > > >> > >> > > > > > > > >> > > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > > I've seen a lot of
> discussions
> > > >> about
> > > >> > >> thin
> > > >> > >> > > > client
> > > >> > >> > > > > > and
> > > >> > >> > > > > > > > >> binary
> > > >> > >> > > > > > > > >> > > > > > protocol,
> > > >> > >> > > > > > > > >> > > > > > > > > but I
> > > >> > >> > > > > > > > >> > > > > > > > > > did not hear anything about
> > > >> > >> transactions
> > > >> > >> > > > > support.
> > > >> > >> > > > > > Do
> > > >> > >> > > > > > > > we
> > > >> > >> > > > > > > > >> > have
> > > >> > >> > > > > > > > >> > > > some
> > > >> > >> > > > > > > > >> > > > > > > draft
> > > >> > >> > > > > > > > >> > > > > > > > > for
> > > >> > >> > > > > > > > >> > > > > > > > > > this purpose?
> > > >> > >> > > > > > > > >> > > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > > As I understand we have
> > several
> > > >> > >> problems:
> > > >> > >> > > > > > > > >> > > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > >    - thread and transaction
> > have
> > > >> hard
> > > >> > >> > > related
> > > >> > >> > > > > (we
> > > >> > >> > > > > > > use
> > > >> > >> > > > > > > > >> > > > > thread-local
> > > >> > >> > > > > > > > >> > > > > > > > > variable
> > > >> > >> > > > > > > > >> > > > > > > > > >    and thread name)
> > > >> > >> > > > > > > > >> > > > > > > > > >    - we can process only one
> > > >> > >> transaction
> > > >> > >> > at
> > > >> > >> > > > the
> > > >> > >> > > > > > same
> > > >> > >> > > > > > > > >> time
> > > >> > >> > > > > > > > >> > in
> > > >> > >> > > > > > > > >> > > > one
> > > >> > >> > > > > > > > >> > > > > > > thread
> > > >> > >> > > > > > > > >> > > > > > > > > (it
> > > >> > >> > > > > > > > >> > > > > > > > > >    mean we need hold thread
> > per
> > > >> > >> client. If
> > > >> > >> > > > > connect
> > > >> > >> > > > > > > 100
> > > >> > >> > > > > > > > >> thin
> > > >> > >> > > > > > > > >> > > > > clients
> > > >> > >> > > > > > > > >> > > > > > > to
> > > >> > >> > > > > > > > >> > > > > > > > 1
> > > >> > >> > > > > > > > >> > > > > > > > > >    server node, then need to
> > hold
> > > >> 100
> > > >> > >> > thread
> > > >> > >> > > > on
> > > >> > >> > > > > > the
> > > >> > >> > > > > > > > >> server
> > > >> > >> > > > > > > > >> > > > side)
> > > >> > >> > > > > > > > >> > > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > > > Let's discuss how we can
> > implement
> > > >> > >> > > > transactions
> > > >> > >> > > > > > for
> > > >> > >> > > > > > > > the
> > > >> > >> > > > > > > > >> > thin
> > > >> > >> > > > > > > > >> > > > > > client.
> > > >> > >> > > > > > > > >> > > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > > >
> > > >> > >> > > > > > > > >> > > > > > >
> > > >> > >> > > > > > > > >> > > > > >
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > > > --
> > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > >> > >> > > > > > > > >> > > > >
> > > >> > >> > > > > > > > >> > > >
> > > >> > >> > > > > > > > >> > >
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >> > --
> > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > >> > >> > > > > > > > >> > GridGain Systems
> > > >> > >> > > > > > > > >> > www.gridgain.com
> > > >> > >> > > > > > > > >> >
> > > >> > >> > > > > > > > >>
> > > >> > >> > > > > > > > >
> > > >> > >> > > > > > > >
> > > >> > >> > > > > > >
> > > >> > >> > > > > >
> > > >> > >> > > > >
> > > >> > >> > > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >>
> > > >> > >
> > > >> >
> > > >>
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
> >
>

[Alexey Plekhanov]

Hi, Igor

1. I think it's better to have the ability to configure transaction
parameters (for example configure default timeout for all clients) on
server-side, then don't have such ability and always use some predefined
client-side values (which can be different for different client
implementations). At least default timeout is more server specific then
client specific parameter since it can affect server-side processes (PME
for example).

2. IgniteUuid has 24 bytes length. This tx id needs to be included to each
cache operation under a transaction. And it almost will not simplify server
code. Also, thin clients don't know how to deal with IgniteUuid now, there
is no such entity in the protocol, there are no described rules on how to
convert it to a string. For monitoring/debugging purposes we should have
the same presentation of this entity on server and client sides. I think if
we need to know real tx id on the client side it's better to additionally
include this value to OP_TX_START response (we also can serialize it as a
string to avoid introducing new entity on client side) or create a new
operation to explicitly request tx id (for example OP_TX_INFO).

3. Make sense, we can reuse deprecated "flags" field (undeprecate it),
which is included now to each cache operation.


пт, 17 мая 2019 г. в 18:49, Igor Sapego <[hidden email]>:

> Hi,
>
> I had a look at IEP and have several comments:
>
> 1. Why would one want to use to use server's default values for Concurrency
> or Isolation?
> I believe, client should have its own defaults which should be explicitly
> documented, so that
> behaviour of transactions will not depend on the server node it was routed
> to. The same goes
> for timeout.
>
> 2. Not sure about transaction ID represented by int. Why not to use
> IgniteUuid? It should simplify
> server code. Also it may help with monitoring/debugging if thin clients and
> server nodes use the
> same identifier for transactions. It does not seem as a big overhead to me
> either.
>
> 3. Maybe it makes sense to add "In transaction" boolean flag to cache
> operation request header
> to avoid bloating message size in non-affected scenarios.
>
> Best Regards,
> Igor
>
>
> On Mon, May 13, 2019 at 1:58 PM Alex Plehanov <[hidden email]>
> wrote:
>
> > Hi, Ivan.
> >
> > Thanks for your comments.
> >
> > 1. Transaction id in thin client protocol it's just a tx counter for the
> > current connection. It's not related to GridCacheVersion. If we want to
> > know GridCacheVersion on the client side, I think we should introduce a
> new
> > type of operation (for example OP_TX_INFO).
> > 2. Error handling is already provided by thin client protocol, even in
> case
> > of empty response. Of course, the client will know if there is a failure
> > occurred during OP_TX_END operation.
> > 3. AFAIK some of thin client implementations already send requests and
> > process responses in an async way (.NET for example). As for java thin
> > client, in the current implementation channel is locked exclusively
> before
> > request send and until the response is processed. I have some ideas about
> > how to fix this (split send/receive process into two different parts and
> > acquire locks for this parts separately or create futures on request sent
> > and complete it after processing the response in a dedicated thread),
> I've
> > created ticket [1] for this issue and will try to implement prototype in
> a
> > couple of days.
> >
> > About suspend/resume, yes, on server-side we should resume tx before each
> > transactional cache operation and suspend the tx after the operation. In
> my
> > opinion, suspend/resume approach have several advantages over approach
> with
> > explicit tx id argument:
> > - Introducing explicit tx id argument for cache operations leads to a
> > significant API change
> > - It's not clear how to use it together with current (tx-per-thread)
> > approach (for example, what if a thread is already held transaction and
> > someone call cache operation with explicit tx id?)
> > - Suspend/resume feature will also be useful for thick clients
> > - Suspend/resume functionality is already partially implemented (for
> > optimistic transactions only)
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-11685
> >
> > пт, 3 мая 2019 г. в 08:10, Павлухин Иван <[hidden email]>:
> >
> > > Hi Alex,
> > >
> > > I went through IEP [1] and I have a couple of questions:
> > > 1. What is going to be used as transaction id? In a described protocol
> > > I see an int field for it. Should not it be GridCacheVersion
> > > corresponding to IgniteInternalTx#xidVersion?
> > > 2. OP_TX_END message assumes an empty response, but I think that
> > > errors during tx finish are possible and should be returned in a
> > > response.
> > > 3. In IEP it is stated that async processing of lock operations should
> > > be introduced on a client side to enable concurrent operations from
> > > different client threads. Do you have an idea how to achieve it?
> > >
> > > Also, a bit about a suspend/resume trait. I tried to think about it
> > > leaving away an existing transactions implementation in Ignite. As I
> > > understood we are going to resume a tx before each cache operation in
> > > the tx and resume the tx after the operation. All this to make an
> > > executing thread available for other operations (e.g. in other txs).
> > > From the first glance it seems like an inversed logic. A
> > > straightforward way is to execute a cache operation within a
> > > particular transaction defined as an explicit tx id argument (e.g.
> > > cache.put(key, value, txid)). Can we do so?
> > >
> > > And leaving for now thin client API. I cannot say that one proposed in
> > > IEP is good or bad. I can only say that it ressembles current thick
> > > client API. And perhaps it should not. I think that we should consider
> > > similar APIs provided by other vendors and keep in mind that we have a
> > > bunch of client implementations for different languages. I suppose
> > > that we can return to it a little bit later. And I hope that we will
> > > do it.
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > >
> > > вт, 30 апр. 2019 г. в 13:24, Alex Plehanov <[hidden email]>:
> > > >
> > > > Hello, Igniters!
> > > >
> > > > I've update IEP [1] and implement PoC according to new approach
> > (multiple
> > > > concurrent transactions per connection).
> > > > But to move forward another feature need to be implemented:
> > > suspend/resume
> > > > for pessimistic transactions (IGNITE-5714 [2]). Implementation of
> > > > suspend/resume is ready now and ticket in 'Patch available' status.
> Can
> > > any
> > > > transactions expert help with review of IGNITE-5714?
> > > >
> > > > [1]:
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > > [2]: https://issues.apache.org/jira/browse/IGNITE-5714
> > > >
> > > > чт, 4 апр. 2019 г. в 11:32, Alex Plehanov <[hidden email]>:
> > > >
> > > > > Vladimir,
> > > > >
> > > > > Ok, then I will rewrite IEP in the near future.
> > > > >
> > > > > чт, 4 апр. 2019 г. в 11:14, Vladimir Ozerov <[hidden email]
> >:
> > > > >
> > > > >> Hi Alex,
> > > > >>
> > > > >> I think we should be able to handle many transactions through a
> > single
> > > > >> connection. This will make our protocol and client implementations
> > > much
> > > > >> more efficient, and simplicity from developer's perspective is not
> > our
> > > > >> goal. Consider normal nodes. We have server nodes and client
> nodes.
> > > You
> > > > >> may
> > > > >> span whatever number of transactions you need, but all of them are
> > > > >> coordinated through a single connection. The same should be
> > > applicable to
> > > > >> thin clients. Protocol is already designed to handle this, as we
> > pass
> > > > >> unique operation ID in order to distinguish one operation from
> > > another. It
> > > > >> is true, though, that we will have to introduce a kind of
> "session"
> > > > >> concept, and pass additional identifier along with cache
> operations,
> > > but
> > > > >> this doesn't sound like a problem to me.
> > > > >>
> > > > >> And provided that currently server-side transactions are bound to
> > > threads
> > > > >> artificially, I would say that the first step in implementation of
> > > > >> transactions on thin clients should be decoupling server-side
> > > transactions
> > > > >> from threads. Without this we will have very inefficient
> > > implementation,
> > > > >> when every new client transaction have to spawn a new thread. This
> > is
> > > slow
> > > > >> and introduces high memory pressure on a cluster node. We already
> > work
> > > > >> this
> > > > >> way for MVCC transactions which are spawned from JDBC driver, and
> > > believe
> > > > >> me, we do not want to replicated this bad practice to other
> clients
> > > :-)
> > > > >>
> > > > >> Vladimir.
> > > > >>
> > > > >> On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <
> > > [hidden email]>
> > > > >> wrote:
> > > > >>
> > > > >> > Guys, so, do we need multiple concurrent transactions per
> > > connection?
> > > > >> >
> > > > >> > There are pros and cons for each approach. Difference between
> > > > >> approaches:
> > > > >> >
> > > > >> > One transaction at a time per connection:
> > > > >> >  - This approach is used in RDBMS world and users got used to it
> > > > >> >  - To use transactions concurrently users need to use different
> > > > >> connections
> > > > >> > and get these connections via something like a connection pool
> > > > >> >  - Easy to implement (in fact, PoC is already done)
> > > > >> >
> > > > >> > Multiple concurrent transactions per connection:
> > > > >> >  - At least for java thin client, we can implement transaction
> per
> > > > >> thread
> > > > >> > approach as implemented now for the thick client (perhaps other
> > thin
> > > > >> > clients can implement the same abstraction)
> > > > >> >  - There is also protocol change for all cache operations needed
> > (to
> > > > >> bind
> > > > >> > cache operation to the transaction)
> > > > >> >  - Significant changes to all implemented clients are needed
> > > > >> >  - Implementation on the server side is more complex
> > > > >> >
> > > > >> > What do you think?
> > > > >> >
> > > > >> >
> > > > >> > вт, 2 апр. 2019 г. в 16:29, Alex Plehanov <
> > [hidden email]
> > > >:
> > > > >> >
> > > > >> > > Ilya,
> > > > >> > >
> > > > >> > > > We should be able to multiplex several transactions using a
> > > single
> > > > >> > > Client connection.
> > > > >> > > In this case, we should significantly change cache operations
> > > syntax
> > > > >> (for
> > > > >> > > each implemented client), to bind each operation to the
> > > transaction.
> > > > >> > >
> > > > >> > > > I want to also ask if "Number of entries participating in
> > > > >> transaction
> > > > >> > > (may be approximate). 0 - default value." is needed.
> > > > >> > > I've tried to minimize API changes between thick and thin
> client
> > > to
> > > > >> > > simplify move from one to another. It's the only reason. But I
> > > agree
> > > > >> with
> > > > >> > > you, the parameter is not very useful.
> > > > >> > >
> > > > >> > >
> > > > >> > > вт, 2 апр. 2019 г. в 14:48, Ilya Kasnacheev <
> > > > >> [hidden email]>:
> > > > >> > >
> > > > >> > >> Hello!
> > > > >> > >>
> > > > >> > >> Pavel, I agree with you thorougly. We should be able to
> > multiplex
> > > > >> > several
> > > > >> > >> transactions using a single Client connection. This means
> > adding
> > > > >> > >> Transaction id parameter to every affected cache operation /
> > SQL
> > > > >> > statement
> > > > >> > >> (if applicable) to make sure we do cache operations on
> relevant
> > > > >> > >> transaction.
> > > > >> > >>
> > > > >> > >> This is how other things work in Ignite, such as
> communication.
> > > We do
> > > > >> > not
> > > > >> > >> open dozens of connections, we multiplex operations
> > > asynchronously
> > > > >> > through
> > > > >> > >> a single connection.
> > > > >> > >>
> > > > >> > >> I think that trying to pool Ignite connections will be highly
> > > > >> > >> inconvenient,
> > > > >> > >> since there is no existing infrastructure for such pooling
> > (like
> > > > >> there
> > > > >> > >> exists for JDBC).
> > > > >> > >>
> > > > >> > >> I want to also ask if "Number of entries participating in
> > > transaction
> > > > >> > (may
> > > > >> > >> be approximate). 0 - default value." is needed. Does it
> > actually
> > > do
> > > > >> > >> anything in our tx protocol? Users of existing APIs are
> already
> > > > >> confused
> > > > >> > >> by
> > > > >> > >> this parameter, if we could get rid of it in thin client
> > > protocol it
> > > > >> > would
> > > > >> > >> be nice clean-up.
> > > > >> > >>
> > > > >> > >> Regards,
> > > > >> > >> --
> > > > >> > >> Ilya Kasnacheev
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> вт, 2 апр. 2019 г. в 09:55, Pavel Tupitsyn <
> > [hidden email]
> > > >:
> > > > >> > >>
> > > > >> > >> > Alex,
> > > > >> > >> >
> > > > >> > >> > > now we can only support one active transaction per
> > connection
> > > > >> > >> >
> > > > >> > >> > I totally understand server-side and protocol limitations
> > that
> > > are
> > > > >> > >> causing
> > > > >> > >> > this.
> > > > >> > >> > But I have no idea how to support this in .NET Thin Client,
> > for
> > > > >> > example.
> > > > >> > >> >
> > > > >> > >> > It is thread-safe and can handle multiple async operations
> in
> > > > >> > parallel.
> > > > >> > >> > But with TX support we have to somehow switch to
> > > single-threaded
> > > > >> mode
> > > > >> > to
> > > > >> > >> > avoid unexpected effects.
> > > > >> > >> >
> > > > >> > >> > Any ideas?
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >> > On Mon, Apr 1, 2019 at 6:38 PM Alex Plehanov <
> > > > >> [hidden email]
> > > > >> > >
> > > > >> > >> > wrote:
> > > > >> > >> >
> > > > >> > >> > > Dmitriy, thank you!
> > > > >> > >> > >
> > > > >> > >> > > Guys, I've created the IEP [1] on wiki, please have a
> look.
> > > > >> > >> > >
> > > > >> > >> > > [1]
> > > > >> > >> > >
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> >
> > > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-34+Thin+client%3A+transactions+support
> > > > >> > >> > >
> > > > >> > >> > >
> > > > >> > >> > > чт, 28 мар. 2019 г. в 14:33, Dmitriy Pavlov <
> > > [hidden email]
> > > > >> >:
> > > > >> > >> > >
> > > > >> > >> > > > Hi,
> > > > >> > >> > > >
> > > > >> > >> > > > I've added permissions to account plehanov.alex
> > > > >> > >> > > >
> > > > >> > >> > > > Recently Infra integrated Apache LDAP with confluence,
> so
> > > it is
> > > > >> > >> > possible
> > > > >> > >> > > to
> > > > >> > >> > > > login using Apache credentials. Probably we can ask
> infra
> > > if
> > > > >> extra
> > > > >> > >> > > > permissions to edit pages should be added for
> committers.
> > > > >> > >> > > >
> > > > >> > >> > > > Sincerely,
> > > > >> > >> > > > Dmitriy Pavlov
> > > > >> > >> > > >
> > > > >> > >> > > > ср, 27 мар. 2019 г. в 13:37, Alex Plehanov <
> > > > >> > [hidden email]
> > > > >> > >> >:
> > > > >> > >> > > >
> > > > >> > >> > > > > Vladimir,
> > > > >> > >> > > > >
> > > > >> > >> > > > > About current tx: ok, then we don't need tx() method
> in
> > > the
> > > > >> > >> interface
> > > > >> > >> > > at
> > > > >> > >> > > > > all (the same cached transaction info user can store
> by
> > > > >> > himself).
> > > > >> > >> > > > >
> > > > >> > >> > > > > About decoupling transactions from threads on the
> > server
> > > > >> side:
> > > > >> > for
> > > > >> > >> > now,
> > > > >> > >> > > > we
> > > > >> > >> > > > > can start with thread-per-connection approach (we
> only
> > > can
> > > > >> > support
> > > > >> > >> > one
> > > > >> > >> > > > > active transaction per connection, see below, so we
> > need
> > > one
> > > > >> > >> > additional
> > > > >> > >> > > > > dedicated thread for each connection with active
> > > > >> transaction),
> > > > >> > and
> > > > >> > >> > > later
> > > > >> > >> > > > > change server-side internals to process client
> > > transactions
> > > > >> in
> > > > >> > any
> > > > >> > >> > > server
> > > > >> > >> > > > > thread (not dedicated to this connection). This
> change
> > > will
> > > > >> not
> > > > >> > >> > affect
> > > > >> > >> > > > the
> > > > >> > >> > > > > thin client protocol, it only affects the server
> side.
> > > > >> > >> > > > > In any case, we can't support concurrent transactions
> > per
> > > > >> > >> connection
> > > > >> > >> > on
> > > > >> > >> > > > > the client side without fundamental changes to the
> > > current
> > > > >> > >> protocol
> > > > >> > >> > > > (cache
> > > > >> > >> > > > > operation doesn't bound to transaction or thread and
> > the
> > > > >> server
> > > > >> > >> > doesn't
> > > > >> > >> > > > > know which thread on the client side do this cache
> > > > >> operation).
> > > > >> > In
> > > > >> > >> my
> > > > >> > >> > > > > opinion, if a user wants to use concurrent
> > transactions,
> > > he
> > > > >> must
> > > > >> > >> use
> > > > >> > >> > > > > different connections from a connection pool.
> > > > >> > >> > > > >
> > > > >> > >> > > > > About semantics of suspend/resume on the client-side:
> > > it's
> > > > >> > >> absolutely
> > > > >> > >> > > > > different than server-side semantics (we don't need
> to
> > do
> > > > >> > >> > > suspend/resume
> > > > >> > >> > > > to
> > > > >> > >> > > > > pass transaction between threads on the client-side),
> > but
> > > > >> can't
> > > > >> > be
> > > > >> > >> > > > > implemented efficiently without implemented
> > > suspend/resume on
> > > > >> > >> > > > server-side.
> > > > >> > >> > > > >
> > > > >> > >> > > > > Can anyone give me permissions to create IEP on
> Apache
> > > wiki?
> > > > >> > >> > > > >
> > > > >> > >> > > > > ср, 27 мар. 2019 г. в 11:59, Vladimir Ozerov <
> > > > >> > >> [hidden email]>:
> > > > >> > >> > > > >
> > > > >> > >> > > > > > Hi Alex,
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > My comments was only about the protocol. Getting
> > > current
> > > > >> info
> > > > >> > >> about
> > > > >> > >> > > > > > transaction should be handled by the client itself.
> > It
> > > is
> > > > >> not
> > > > >> > >> > > protocl's
> > > > >> > >> > > > > > concern. Same about other APIs and behavior in case
> > > another
> > > > >> > >> > > transaction
> > > > >> > >> > > > > is
> > > > >> > >> > > > > > attempted from the same thread.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Putting protocol aside, transaction support is
> > > complicated
> > > > >> > >> matter.
> > > > >> > >> > I
> > > > >> > >> > > > > would
> > > > >> > >> > > > > > propose to route through IEP and wide community
> > > > >> discussion. We
> > > > >> > >> need
> > > > >> > >> > > to
> > > > >> > >> > > > > > review API and semantics very carefully, taking
> > > > >> SUSPEND/RESUME
> > > > >> > >> in
> > > > >> > >> > > > count.
> > > > >> > >> > > > > > Also I do not see how we support client
> transactions
> > > > >> > efficiently
> > > > >> > >> > > > without
> > > > >> > >> > > > > > decoupling transactions from threads on the server
> > side
> > > > >> first.
> > > > >> > >> > > Because
> > > > >> > >> > > > > > without it you will need a dedicated server thread
> > for
> > > > >> every
> > > > >> > >> > client's
> > > > >> > >> > > > > > transaction which is slow and may even crash the
> > > server.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > Vladimir.
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > On Wed, Mar 27, 2019 at 11:44 AM Alex Plehanov <
> > > > >> > >> > > > [hidden email]>
> > > > >> > >> > > > > > wrote:
> > > > >> > >> > > > > >
> > > > >> > >> > > > > > > Vladimir, what if we want to get current
> > transaction
> > > info
> > > > >> > >> (tx()
> > > > >> > >> > > > > method)?
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Does close() method mapped to TX_END(rollback)?
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > For example, this code:
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > try(tx = txStart()) {
> > > > >> > >> > > > > > >     tx.commit();
> > > > >> > >> > > > > > > }
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Will produce:
> > > > >> > >> > > > > > > TX_START
> > > > >> > >> > > > > > > TX_END(commit)
> > > > >> > >> > > > > > > TX_END(rollback)
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > Am I understand you right?
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > About xid. There is yet another proposal. Use
> some
> > > unique
> > > > >> > per
> > > > >> > >> > > > > connection
> > > > >> > >> > > > > > id
> > > > >> > >> > > > > > > (integer, simple counter) for identifying the
> > > > >> transaction on
> > > > >> > >> > > > > > > commit/rollback message. The client gets this id
> > > from the
> > > > >> > >> server
> > > > >> > >> > > with
> > > > >> > >> > > > > > > transaction info and sends it back to the server
> > when
> > > > >> trying
> > > > >> > >> to
> > > > >> > >> > > > > > > commit/rollback transaction. This id is not shown
> > to
> > > > >> users.
> > > > >> > >> But
> > > > >> > >> > > also
> > > > >> > >> > > > we
> > > > >> > >> > > > > > can
> > > > >> > >> > > > > > > pass from server to client real transaction id
> > (xid)
> > > with
> > > > >> > >> > > transaction
> > > > >> > >> > > > > > info
> > > > >> > >> > > > > > > for diagnostic purposes.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > And one more question: what should we do if the
> > > client
> > > > >> > starts
> > > > >> > >> a
> > > > >> > >> > new
> > > > >> > >> > > > > > > transaction without ending the old one? Should we
> > > end the
> > > > >> > old
> > > > >> > >> > > > > transaction
> > > > >> > >> > > > > > > implicitly (rollback) or throw an exception to
> the
> > > > >> client?
> > > > >> > In
> > > > >> > >> my
> > > > >> > >> > > > > opinion,
> > > > >> > >> > > > > > > the first option is better. For example, if we
> got
> > a
> > > > >> > >> previously
> > > > >> > >> > > used
> > > > >> > >> > > > > > > connection from the connection pool, we should
> not
> > > worry
> > > > >> > about
> > > > >> > >> > any
> > > > >> > >> > > > > > > uncompleted transaction started by the previous
> > user
> > > of
> > > > >> this
> > > > >> > >> > > > > connection.
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > ср, 27 мар. 2019 г. в 11:02, Vladimir Ozerov <
> > > > >> > >> > [hidden email]
> > > > >> > >> > > >:
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > > As far as SUSPEND/RESUME/SAVEPOINT - we do not
> > > support
> > > > >> > them
> > > > >> > >> > yet,
> > > > >> > >> > > > and
> > > > >> > >> > > > > > > adding
> > > > >> > >> > > > > > > > them in future should not conflict with simple
> > > > >> START/END
> > > > >> > >> > > > > > infrastructure.
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > > > On Wed, Mar 27, 2019 at 11:00 AM Vladimir
> Ozerov
> > <
> > > > >> > >> > > > > [hidden email]
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > > > > wrote:
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > > > > Hi Alex,
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > I am not sure we need 5 commands. Wouldn't it
> > be
> > > > >> enough
> > > > >> > to
> > > > >> > >> > have
> > > > >> > >> > > > > only
> > > > >> > >> > > > > > > two?
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > START - accepts optional parameters, returns
> > > > >> transaction
> > > > >> > >> info
> > > > >> > >> > > > > > > > > END - provides commit flag, returns void
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > Vladimir.
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > > On Wed, Mar 27, 2019 at 8:26 AM Alex
> Plehanov <
> > > > >> > >> > > > > > [hidden email]
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > > > > wrote:
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > > >> Sergey, yes, the close is something like
> > silent
> > > > >> > rollback.
> > > > >> > >> > But
> > > > >> > >> > > we
> > > > >> > >> > > > > can
> > > > >> > >> > > > > > > > >> also implement this on the client side, just
> > > using
> > > > >> > >> rollback
> > > > >> > >> > > and
> > > > >> > >> > > > > > > ignoring
> > > > >> > >> > > > > > > > >> errors in the response.
> > > > >> > >> > > > > > > > >>
> > > > >> > >> > > > > > > > >> ср, 27 мар. 2019 г. в 00:04, Sergey Kozlov <
> > > > >> > >> > > > [hidden email]
> > > > >> > >> > > > > >:
> > > > >> > >> > > > > > > > >>
> > > > >> > >> > > > > > > > >> > Nikolay
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > Am I correctly understand you points:
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> >    - close: rollback
> > > > >> > >> > > > > > > > >> >    - commit, close: do nothing
> > > > >> > >> > > > > > > > >> >    - rollback, close: do what? (I suppose
> > > nothing)
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > Also you assume that after commit/rollback
> > we
> > > may
> > > > >> > need
> > > > >> > >> to
> > > > >> > >> > > free
> > > > >> > >> > > > > > some
> > > > >> > >> > > > > > > > >> > resources on server node(s)or just do on
> > > client
> > > > >> > started
> > > > >> > >> > TX?
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > On Tue, Mar 26, 2019 at 10:41 PM Alex
> > > Plehanov <
> > > > >> > >> > > > > > > > [hidden email]
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > wrote:
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > > Sergey, we have the close() method in
> the
> > > thick
> > > > >> > >> client,
> > > > >> > >> > > it's
> > > > >> > >> > > > > > > > behavior
> > > > >> > >> > > > > > > > >> is
> > > > >> > >> > > > > > > > >> > > slightly different than rollback()
> method
> > > (it
> > > > >> > should
> > > > >> > >> > > > rollback
> > > > >> > >> > > > > if
> > > > >> > >> > > > > > > the
> > > > >> > >> > > > > > > > >> > > transaction is not committed and do
> > nothing
> > > if
> > > > >> the
> > > > >> > >> > > > transaction
> > > > >> > >> > > > > > is
> > > > >> > >> > > > > > > > >> already
> > > > >> > >> > > > > > > > >> > > committed). I think we should support
> > > > >> > >> try-with-resource
> > > > >> > >> > > > > > semantics
> > > > >> > >> > > > > > > in
> > > > >> > >> > > > > > > > >> the
> > > > >> > >> > > > > > > > >> > > thin client and OP_TX_CLOSE will be
> useful
> > > here.
> > > > >> > >> > > > > > > > >> > >
> > > > >> > >> > > > > > > > >> > > Nikolay, suspend/resume didn't work yet
> > for
> > > > >> > >> pessimistic
> > > > >> > >> > > > > > > > transactions.
> > > > >> > >> > > > > > > > >> > Also,
> > > > >> > >> > > > > > > > >> > > the main goal of suspend/resume
> operations
> > > is to
> > > > >> > >> support
> > > > >> > >> > > > > > > transaction
> > > > >> > >> > > > > > > > >> > > passing between threads. In the thin
> > > client, the
> > > > >> > >> > > transaction
> > > > >> > >> > > > > is
> > > > >> > >> > > > > > > > bound
> > > > >> > >> > > > > > > > >> to
> > > > >> > >> > > > > > > > >> > > the client connection, not client
> thread.
> > I
> > > > >> think
> > > > >> > >> > passing
> > > > >> > >> > > a
> > > > >> > >> > > > > > > > >> transaction
> > > > >> > >> > > > > > > > >> > > between different client connections is
> > not
> > > a
> > > > >> very
> > > > >> > >> > useful
> > > > >> > >> > > > > case.
> > > > >> > >> > > > > > > > >> > >
> > > > >> > >> > > > > > > > >> > > вт, 26 мар. 2019 г. в 22:17, Nikolay
> > > Izhikov <
> > > > >> > >> > > > > > [hidden email]
> > > > >> > >> > > > > > > >:
> > > > >> > >> > > > > > > > >> > >
> > > > >> > >> > > > > > > > >> > > > Hello, Alex.
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > We also have suspend and resume
> > > operations.
> > > > >> > >> > > > > > > > >> > > > I think we should support them
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > вт, 26 марта 2019 г., 22:07 Sergey
> > Kozlov
> > > <
> > > > >> > >> > > > > > [hidden email]
> > > > >> > >> > > > > > > >:
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > > Hi
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > > Looks like I missed something but
> why
> > we
> > > > >> need
> > > > >> > >> > > > OP_TX_CLOSE
> > > > >> > >> > > > > > > > >> operation?
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > > Also I suggest to reserve a code for
> > > > >> SAVEPOINT
> > > > >> > >> > > operation
> > > > >> > >> > > > > > which
> > > > >> > >> > > > > > > > >> very
> > > > >> > >> > > > > > > > >> > > > useful
> > > > >> > >> > > > > > > > >> > > > > to understand where transaction has
> > been
> > > > >> rolled
> > > > >> > >> back
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > > On Tue, Mar 26, 2019 at 6:07 PM Alex
> > > > >> Plehanov <
> > > > >> > >> > > > > > > > >> > [hidden email]
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > > > > wrote:
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > > > Hello Igniters!
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > I want to pick up the ticket
> > > IGNITE-7369
> > > > >> and
> > > > >> > >> add
> > > > >> > >> > > > > > > transactions
> > > > >> > >> > > > > > > > >> > support
> > > > >> > >> > > > > > > > >> > > > to
> > > > >> > >> > > > > > > > >> > > > > > our thin client implementation.
> > > > >> > >> > > > > > > > >> > > > > > I've looked at our current
> > > implementation
> > > > >> and
> > > > >> > >> have
> > > > >> > >> > > > some
> > > > >> > >> > > > > > > > >> proposals
> > > > >> > >> > > > > > > > >> > to
> > > > >> > >> > > > > > > > >> > > > > > support transactions:
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > Add new operations to thin client
> > > > >> protocol:
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > >     OP_TX_GET, 4000, Get current
> > > > >> transaction
> > > > >> > >> for
> > > > >> > >> > > > client
> > > > >> > >> > > > > > > > >> connection
> > > > >> > >> > > > > > > > >> > > > > >     OP_TX_START, 4001, Start a new
> > > > >> > transaction
> > > > >> > >> > > > > > > > >> > > > > >     OP_TX_COMMIT, 4002, Commit
> > > transaction
> > > > >> > >> > > > > > > > >> > > > > >     OP_TX_ROLLBACK, 4003, Rollback
> > > > >> > transaction
> > > > >> > >> > > > > > > > >> > > > > >     OP_TX_CLOSE, 4004, Close
> > > transaction
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > From the client side (java) new
> > > interfaces
> > > > >> > >> will be
> > > > >> > >> > > > > added:
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > public interface
> ClientTransactions
> > {
> > > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > > txStart();
> > > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > > > >> > >> > > > > > txStart(TransactionConcurrency
> > > > >> > >> > > > > > > > >> > > > concurrency,
> > > > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation);
> > > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction
> > > > >> > >> > > > > > txStart(TransactionConcurrency
> > > > >> > >> > > > > > > > >> > > > concurrency,
> > > > >> > >> > > > > > > > >> > > > > > TransactionIsolation isolation,
> long
> > > > >> timeout,
> > > > >> > >> int
> > > > >> > >> > > > > txSize);
> > > > >> > >> > > > > > > > >> > > > > >     public ClientTransaction tx();
> > //
> > > Get
> > > > >> > >> current
> > > > >> > >> > > > > > connection
> > > > >> > >> > > > > > > > >> > > > transaction
> > > > >> > >> > > > > > > > >> > > > > >     public ClientTransactions
> > > > >> > withLabel(String
> > > > >> > >> > lb);
> > > > >> > >> > > > > > > > >> > > > > > }
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > public interface ClientTransaction
> > > extends
> > > > >> > >> > > > > AutoCloseable {
> > > > >> > >> > > > > > > > >> > > > > >     public IgniteUuid xid(); // Do
> > we
> > > need
> > > > >> > it?
> > > > >> > >> > > > > > > > >> > > > > >     public TransactionIsolation
> > > > >> isolation();
> > > > >> > >> > > > > > > > >> > > > > >     public TransactionConcurrency
> > > > >> > >> concurrency();
> > > > >> > >> > > > > > > > >> > > > > >     public long timeout();
> > > > >> > >> > > > > > > > >> > > > > >     public String label();
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > >     public void commit();
> > > > >> > >> > > > > > > > >> > > > > >     public void rollback();
> > > > >> > >> > > > > > > > >> > > > > >     public void close();
> > > > >> > >> > > > > > > > >> > > > > > }
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > From the server side, I think as a
> > > first
> > > > >> step
> > > > >> > >> > (while
> > > > >> > >> > > > > > > > >> transactions
> > > > >> > >> > > > > > > > >> > > > > > suspend/resume is not fully
> > > implemented)
> > > > >> we
> > > > >> > can
> > > > >> > >> > use
> > > > >> > >> > > > the
> > > > >> > >> > > > > > same
> > > > >> > >> > > > > > > > >> > approach
> > > > >> > >> > > > > > > > >> > > > as
> > > > >> > >> > > > > > > > >> > > > > > for JDBC: add a new worker to each
> > > > >> > >> > > > ClientRequestHandler
> > > > >> > >> > > > > > and
> > > > >> > >> > > > > > > > >> process
> > > > >> > >> > > > > > > > >> > > > > > requests by this worker if the
> > > > >> transaction is
> > > > >> > >> > > started
> > > > >> > >> > > > > > > > >> explicitly.
> > > > >> > >> > > > > > > > >> > > > > > ClientRequestHandler is bound to
> > > client
> > > > >> > >> > connection,
> > > > >> > >> > > so
> > > > >> > >> > > > > > there
> > > > >> > >> > > > > > > > >> will
> > > > >> > >> > > > > > > > >> > be
> > > > >> > >> > > > > > > > >> > > > 1:1
> > > > >> > >> > > > > > > > >> > > > > > relation between client connection
> > and
> > > > >> > thread,
> > > > >> > >> > which
> > > > >> > >> > > > > > process
> > > > >> > >> > > > > > > > >> > > operations
> > > > >> > >> > > > > > > > >> > > > > in
> > > > >> > >> > > > > > > > >> > > > > > a transaction.
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > Also, there is a couple of issues
> I
> > > want
> > > > >> to
> > > > >> > >> > discuss:
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > We have overloaded method txStart
> > > with a
> > > > >> > >> different
> > > > >> > >> > > set
> > > > >> > >> > > > > of
> > > > >> > >> > > > > > > > >> > arguments.
> > > > >> > >> > > > > > > > >> > > > Some
> > > > >> > >> > > > > > > > >> > > > > > of the arguments may be missing.
> To
> > > pass
> > > > >> > >> arguments
> > > > >> > >> > > > with
> > > > >> > >> > > > > > > > >> OP_TX_START
> > > > >> > >> > > > > > > > >> > > > > > operation we have the next
> options:
> > > > >> > >> > > > > > > > >> > > > > >  * Serialize full set of arguments
> > > and use
> > > > >> > some
> > > > >> > >> > > value
> > > > >> > >> > > > > for
> > > > >> > >> > > > > > > > >> missing
> > > > >> > >> > > > > > > > >> > > > > > arguments. For example -1 for
> > int/long
> > > > >> types
> > > > >> > >> and
> > > > >> > >> > > null
> > > > >> > >> > > > > for
> > > > >> > >> > > > > > > > string
> > > > >> > >> > > > > > > > >> > > type.
> > > > >> > >> > > > > > > > >> > > > We
> > > > >> > >> > > > > > > > >> > > > > > can't use 0 for int/long types
> > since 0
> > > > >> it's a
> > > > >> > >> > valid
> > > > >> > >> > > > > value
> > > > >> > >> > > > > > > for
> > > > >> > >> > > > > > > > >> > > > > concurrency,
> > > > >> > >> > > > > > > > >> > > > > > isolation and timeout arguments.
> > > > >> > >> > > > > > > > >> > > > > >  * Serialize arguments as a
> > > collection of
> > > > >> > >> > > > property-value
> > > > >> > >> > > > > > > pairs
> > > > >> > >> > > > > > > > >> > (like
> > > > >> > >> > > > > > > > >> > > > it's
> > > > >> > >> > > > > > > > >> > > > > > implemented now for
> > > CacheConfiguration).
> > > > >> In
> > > > >> > >> this
> > > > >> > >> > > case
> > > > >> > >> > > > > only
> > > > >> > >> > > > > > > > >> > explicitly
> > > > >> > >> > > > > > > > >> > > > > > provided arguments will be
> > serialized.
> > > > >> > >> > > > > > > > >> > > > > > Which way is better? The simplest
> > > > >> solution is
> > > > >> > >> to
> > > > >> > >> > use
> > > > >> > >> > > > the
> > > > >> > >> > > > > > > first
> > > > >> > >> > > > > > > > >> > option
> > > > >> > >> > > > > > > > >> > > > > and I
> > > > >> > >> > > > > > > > >> > > > > > want to use it if there were no
> > > > >> objections.
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > Do we need transaction id (xid) on
> > the
> > > > >> client
> > > > >> > >> > side?
> > > > >> > >> > > > > > > > >> > > > > > If yes, we can pass xid along with
> > > > >> > >> OP_TX_COMMIT,
> > > > >> > >> > > > > > > > OP_TX_ROLLBACK,
> > > > >> > >> > > > > > > > >> > > > > > OP_TX_CLOSE operations back to the
> > > server
> > > > >> and
> > > > >> > >> do
> > > > >> > >> > > > > > additional
> > > > >> > >> > > > > > > > >> check
> > > > >> > >> > > > > > > > >> > on
> > > > >> > >> > > > > > > > >> > > > the
> > > > >> > >> > > > > > > > >> > > > > > server side (current transaction
> id
> > > for
> > > > >> > >> connection
> > > > >> > >> > > ==
> > > > >> > >> > > > > > > > >> transaction
> > > > >> > >> > > > > > > > >> > id
> > > > >> > >> > > > > > > > >> > > > > passed
> > > > >> > >> > > > > > > > >> > > > > > from client side). This, perhaps,
> > will
> > > > >> > protect
> > > > >> > >> > > clients
> > > > >> > >> > > > > > > against
> > > > >> > >> > > > > > > > >> some
> > > > >> > >> > > > > > > > >> > > > > errors
> > > > >> > >> > > > > > > > >> > > > > > (for example when client try to
> > commit
> > > > >> > outdated
> > > > >> > >> > > > > > > transaction).
> > > > >> > >> > > > > > > > >> But
> > > > >> > >> > > > > > > > >> > > > > > currently, we don't have data type
> > > > >> IgniteUuid
> > > > >> > >> in
> > > > >> > >> > > thin
> > > > >> > >> > > > > > client
> > > > >> > >> > > > > > > > >> > > protocol.
> > > > >> > >> > > > > > > > >> > > > Do
> > > > >> > >> > > > > > > > >> > > > > > we need to add it too?
> > > > >> > >> > > > > > > > >> > > > > > Also, we can pass xid as a string
> > > just to
> > > > >> > >> inform
> > > > >> > >> > the
> > > > >> > >> > > > > > client
> > > > >> > >> > > > > > > > and
> > > > >> > >> > > > > > > > >> do
> > > > >> > >> > > > > > > > >> > > not
> > > > >> > >> > > > > > > > >> > > > > pass
> > > > >> > >> > > > > > > > >> > > > > > it back to the server with
> > > commit/rollback
> > > > >> > >> > > operation.
> > > > >> > >> > > > > > > > >> > > > > > Or not to pass xid at all (.NET
> > thick
> > > > >> client
> > > > >> > >> works
> > > > >> > >> > > > this
> > > > >> > >> > > > > > way
> > > > >> > >> > > > > > > as
> > > > >> > >> > > > > > > > >> far
> > > > >> > >> > > > > > > > >> > > as I
> > > > >> > >> > > > > > > > >> > > > > > know).
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > What do you think?
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > ср, 7 мар. 2018 г. в 16:22,
> Vladimir
> > > > >> Ozerov <
> > > > >> > >> > > > > > > > >> [hidden email]
> > > > >> > >> > > > > > > > >> > >:
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > We already have transactions
> > > support in
> > > > >> > JDBC
> > > > >> > >> > > driver
> > > > >> > >> > > > in
> > > > >> > >> > > > > > TX
> > > > >> > >> > > > > > > > SQL
> > > > >> > >> > > > > > > > >> > > branch
> > > > >> > >> > > > > > > > >> > > > > > > (ignite-4191). Currently it is
> > > > >> implemented
> > > > >> > >> > through
> > > > >> > >> > > > > > > separate
> > > > >> > >> > > > > > > > >> > thread,
> > > > >> > >> > > > > > > > >> > > > > which
> > > > >> > >> > > > > > > > >> > > > > > > is not that efficient. Ideally
> we
> > > need
> > > > >> to
> > > > >> > >> finish
> > > > >> > >> > > > > > > decoupling
> > > > >> > >> > > > > > > > >> > > > > transactions
> > > > >> > >> > > > > > > > >> > > > > > > from threads. But alternatively
> we
> > > can
> > > > >> > change
> > > > >> > >> > the
> > > > >> > >> > > > > logic
> > > > >> > >> > > > > > on
> > > > >> > >> > > > > > > > >> how we
> > > > >> > >> > > > > > > > >> > > > > assign
> > > > >> > >> > > > > > > > >> > > > > > > thread ID to specific
> transaction
> > > and
> > > > >> > >> > > "impersonate"
> > > > >> > >> > > > > thin
> > > > >> > >> > > > > > > > >> client
> > > > >> > >> > > > > > > > >> > > > worker
> > > > >> > >> > > > > > > > >> > > > > > > threads when serving requests
> from
> > > > >> multiple
> > > > >> > >> > users.
> > > > >> > >> > > > > > > > >> > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > On Tue, Mar 6, 2018 at 10:01 PM,
> > > Denis
> > > > >> > Magda
> > > > >> > >> <
> > > > >> > >> > > > > > > > >> [hidden email]>
> > > > >> > >> > > > > > > > >> > > > > wrote:
> > > > >> > >> > > > > > > > >> > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > Here is an original discussion
> > > with a
> > > > >> > >> > reference
> > > > >> > >> > > to
> > > > >> > >> > > > > the
> > > > >> > >> > > > > > > > JIRA
> > > > >> > >> > > > > > > > >> > > ticket:
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > http://apache-ignite-developers.2346864.n4.nabble
> > > > >> > >> > > > .
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > >
> > > > >> > com/Re-Transaction-operations-using-the-Ignite-Thin-Client-
> > > > >> > >> > > > > > > > >> > > > > > > > Protocol-td25914.html
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > --
> > > > >> > >> > > > > > > > >> > > > > > > > Denis
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > On Tue, Mar 6, 2018 at 9:18
> AM,
> > > > >> Dmitriy
> > > > >> > >> > > Setrakyan
> > > > >> > >> > > > <
> > > > >> > >> > > > > > > > >> > > > > > [hidden email]
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > wrote:
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > Hi Dmitriy. I don't think we
> > > have a
> > > > >> > >> design
> > > > >> > >> > > > > proposal
> > > > >> > >> > > > > > > for
> > > > >> > >> > > > > > > > >> > > > transaction
> > > > >> > >> > > > > > > > >> > > > > > > > support
> > > > >> > >> > > > > > > > >> > > > > > > > > in thin clients. Do you mind
> > > taking
> > > > >> > this
> > > > >> > >> > > > > initiative
> > > > >> > >> > > > > > > and
> > > > >> > >> > > > > > > > >> > > creating
> > > > >> > >> > > > > > > > >> > > > an
> > > > >> > >> > > > > > > > >> > > > > > IEP
> > > > >> > >> > > > > > > > >> > > > > > > > on
> > > > >> > >> > > > > > > > >> > > > > > > > > Wiki?
> > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > D.
> > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > On Tue, Mar 6, 2018 at 8:46
> > AM,
> > > > >> Dmitriy
> > > > >> > >> > > > > Govorukhin <
> > > > >> > >> > > > > > > > >> > > > > > > > >
> [hidden email]>
> > > > >> wrote:
> > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > > Hi, Igniters.
> > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > > I've seen a lot of
> > discussions
> > > > >> about
> > > > >> > >> thin
> > > > >> > >> > > > client
> > > > >> > >> > > > > > and
> > > > >> > >> > > > > > > > >> binary
> > > > >> > >> > > > > > > > >> > > > > > protocol,
> > > > >> > >> > > > > > > > >> > > > > > > > > but I
> > > > >> > >> > > > > > > > >> > > > > > > > > > did not hear anything
> about
> > > > >> > >> transactions
> > > > >> > >> > > > > support.
> > > > >> > >> > > > > > Do
> > > > >> > >> > > > > > > > we
> > > > >> > >> > > > > > > > >> > have
> > > > >> > >> > > > > > > > >> > > > some
> > > > >> > >> > > > > > > > >> > > > > > > draft
> > > > >> > >> > > > > > > > >> > > > > > > > > for
> > > > >> > >> > > > > > > > >> > > > > > > > > > this purpose?
> > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > > As I understand we have
> > > several
> > > > >> > >> problems:
> > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > >    - thread and
> transaction
> > > have
> > > > >> hard
> > > > >> > >> > > related
> > > > >> > >> > > > > (we
> > > > >> > >> > > > > > > use
> > > > >> > >> > > > > > > > >> > > > > thread-local
> > > > >> > >> > > > > > > > >> > > > > > > > > variable
> > > > >> > >> > > > > > > > >> > > > > > > > > >    and thread name)
> > > > >> > >> > > > > > > > >> > > > > > > > > >    - we can process only
> one
> > > > >> > >> transaction
> > > > >> > >> > at
> > > > >> > >> > > > the
> > > > >> > >> > > > > > same
> > > > >> > >> > > > > > > > >> time
> > > > >> > >> > > > > > > > >> > in
> > > > >> > >> > > > > > > > >> > > > one
> > > > >> > >> > > > > > > > >> > > > > > > thread
> > > > >> > >> > > > > > > > >> > > > > > > > > (it
> > > > >> > >> > > > > > > > >> > > > > > > > > >    mean we need hold
> thread
> > > per
> > > > >> > >> client. If
> > > > >> > >> > > > > connect
> > > > >> > >> > > > > > > 100
> > > > >> > >> > > > > > > > >> thin
> > > > >> > >> > > > > > > > >> > > > > clients
> > > > >> > >> > > > > > > > >> > > > > > > to
> > > > >> > >> > > > > > > > >> > > > > > > > 1
> > > > >> > >> > > > > > > > >> > > > > > > > > >    server node, then need
> to
> > > hold
> > > > >> 100
> > > > >> > >> > thread
> > > > >> > >> > > > on
> > > > >> > >> > > > > > the
> > > > >> > >> > > > > > > > >> server
> > > > >> > >> > > > > > > > >> > > > side)
> > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > > > Let's discuss how we can
> > > implement
> > > > >> > >> > > > transactions
> > > > >> > >> > > > > > for
> > > > >> > >> > > > > > > > the
> > > > >> > >> > > > > > > > >> > thin
> > > > >> > >> > > > > > > > >> > > > > > client.
> > > > >> > >> > > > > > > > >> > > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > > >
> > > > >> > >> > > > > > > > >> > > > > > >
> > > > >> > >> > > > > > > > >> > > > > >
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > > > --
> > > > >> > >> > > > > > > > >> > > > > Sergey Kozlov
> > > > >> > >> > > > > > > > >> > > > > GridGain Systems
> > > > >> > >> > > > > > > > >> > > > > www.gridgain.com
> > > > >> > >> > > > > > > > >> > > > >
> > > > >> > >> > > > > > > > >> > > >
> > > > >> > >> > > > > > > > >> > >
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >> > --
> > > > >> > >> > > > > > > > >> > Sergey Kozlov
> > > > >> > >> > > > > > > > >> > GridGain Systems
> > > > >> > >> > > > > > > > >> > www.gridgain.com
> > > > >> > >> > > > > > > > >> >
> > > > >> > >> > > > > > > > >>
> > > > >> > >> > > > > > > > >
> > > > >> > >> > > > > > > >
> > > > >> > >> > > > > > >
> > > > >> > >> > > > > >
> > > > >> > >> > > > >
> > > > >> > >> > > >
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> > >
> >
>

[Igor Sapego-2]

1. In my opinion, having client-specific transaction parameters is expected
for
client when have different arguments depending on server seems unexpected
and can lead to hard-to-debug bugs and issues when updating from old to new
server versions. Also it goes against common practice with arguments of thin
client and thus, may be even more unexpected.

I believe that if we want to add ability to client to adopt some server's
defaults
we should implement it as separate feature, and it should not be a default
behaviour for client, user should explicitly state that they want this
behaviour,
so it won't be unexpected for them.

3. "Flags" field looks like a good solution to me.

Best Regards,
Igor


On Mon, May 20, 2019 at 12:58 PM Alex Plehanov <[hidden email]>
wrote:

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

[Ivan Pavlukhin]

Igor, Alex,

Regarding point 1. I must say that SQL vendors usually allow to
configure default timeouts and a transaction isolation on a server
side. E.g. in MySQL you can do a following:
set local tx_isolation = <isolation> -- per SQL client session
(usually physical network connection)
set global tx_isolation = <isolation> -- global settings, all clients
(which does not override it) are affected

So, if it is a standard practice why should do it differently? If it
is not, we can continue discussion. Do we have some examples following
opposite way (client-wide default setting)?

пн, 20 мая 2019 г. в 13:50, Igor Sapego <[hidden email]>:

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

--
Best regards,
Ivan Pavlukhin

[Igor Sapego-2]

Ivan,

This may be a good point for a DBMS, but Ignite is much more than just a
DBMS and Ignite client code is not just an SQL query (which execution
inherently heavily depends on DBMS). With database user is expecting that
server have a lot of control on query execution. But with Ignite, in my
opinion,
user writes generic code including business logic in native language and may
expect more deterministic behaviour from a client.

Also, thick clients do not use server-side defaults.

Of course, this question is debatable and It's not like I 100% against
server-side
defaults here, I just suggest to discuss it in more detail.

Best Regards,
Igor


On Mon, May 20, 2019 at 2:21 PM Павлухин Иван <[hidden email]> wrote:

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

[Alexey Plekhanov]

Igor,

Perhaps we don't really need to use server's default values for tx
parameters. It's a minor fix and can be easily implemented if it will be
required in the future.
I will update IEP tomorrow regarding point 1 and point 3.
Thanks for your feedback.

пн, 20 мая 2019 г. в 15:24, Igor Sapego <[hidden email]>:

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

[Ivan Pavlukhin]

Alex,

Are you going to introduce settings specifying default values for tx
concurrency and isolation in client configuration?

пн, 20 мая 2019 г. в 19:34, Alex Plehanov <[hidden email]>:

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

--
Best regards,
Ivan Pavlukhin

[Alexey Plekhanov]

Ivan,

Yes, I have plans to do that (at least for java thin client). Something
like new class "ClientTransactionConfiguration" inside
"ClientConfiguration".

вт, 21 мая 2019 г. в 13:37, Павлухин Иван <[hidden email]>:

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

[Alexey Plekhanov]

Guys,

I've updated the IEP [1]. Please have a look.

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


вт, 21 мая 2019 г., 14:19 Alex Plehanov <[hidden email]>:

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

[Ivan Pavlukhin]

Hi Alex,

Regarding a problem with possible deadlock when two concurrent
transactions from the same client are trying to lock the same key and
an issue [1]. It seems to me that without fixing the issue [1] a
client transactions feature is not practical. Everyone who uses a
client from multiple threads can face a deadlock which is impossible
to deal with. Or am I missing something here?

One workaround I can imagine is failing a transactions execution from
concurrent threads for a first time.

[1] https://issues.apache.org/jira/browse/IGNITE-11685

вт, 21 мая 2019 г. в 19:05, Alex Plehanov <[hidden email]>:

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

--
Best regards,
Ivan Pavlukhin

[Alexey Plekhanov]

Hi Ivan.

Thin client transactions support is not only for java thin client. There
are other clients, some of them already work in async mode.
Ticket IGNITE-11685 already has draft implementation too, but now it's
based on some changes to java thin client which were made by "transaction
support" implementation. I think this ticket will be ready in a couple of
days after "transaction support" will be merged. And both patches will be
included in the same release.

пн, 27 мая 2019 г. в 11:57, Павлухин Иван <[hidden email]>:

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

[Ivan Pavlukhin]

Alex,

I am quite curious about async implementations from other clients. Is
there any design document describing such implementations? Does .NET
client have such capability?

Actually, I forgot to finish my previous message. One of my concerns
is that a concurrent response dispatch does not sound as a trivial
thing. So, I would like to understand if we already have a good
approach for that. If not then I suppose it worth a discussion.

пн, 27 мая 2019 г. в 12:51, Alex Plehanov <[hidden email]>:

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

--
Best regards,
Ivan Pavlukhin

[Alexey Plekhanov]

Ivan,

Yes, .NET client has such capability. Pavel Tupitsyn already mentions it in
this thread. As far as I understand, in .NET client implementation to
dispatch responses dedicated thread is used.
In a draft implementation of IGNITE-11685 I've used another approach: each
request thread can read a response (if lock is acquired by this thread
successfully) and complete a future of its own request or another threads
request.

пн, 27 мая 2019 г. в 13:01, Павлухин Иван <[hidden email]>:

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