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
