As far as SUSPEND/RESUME/SAVEPOINT - we do not support them yet, and adding
them in future should not conflict with simple START/END infrastructure.
On Wed, Mar 27, 2019 at 11:00 AM Vladimir Ozerov <voze...@gridgain.com>
wrote:
> 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
>> >
>>
>
