ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Thin client: transactions support
Date Thu, 04 Apr 2019 08:13:37 GMT
Hi Alex,

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

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

Vladimir.

On Thu, Apr 4, 2019 at 10:08 AM Alex Plehanov <plehanov.alex@gmail.com>
wrote:

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

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