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.a...@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 <nizhi...@apache.org>:
>
> > 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
> > >
> >
>
--
Sergey Kozlov
GridGain Systems
www.gridgain.com
