Hello, Alex.
We also have suspend and resume operations.
I think we should support them
вт, 26 марта 2019 г., 22:07 Sergey Kozlov <skoz...@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.a...@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 <voze...@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 <dma...@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 <
> > dsetrak...@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.govoruk...@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
>
