ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Plehanov <plehanov.a...@gmail.com>
Subject Re: Thin client: transactions support
Date Tue, 02 Apr 2019 13:29:56 GMT
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