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, 26 Mar 2019 19:41:17 GMT
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
> >
>

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