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.a...@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 <skoz...@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.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
> >
>
