You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

IDIEP-34
Author
Sponsor
Created

 

Status
DRAFT


Motivation

Currently transactions are not supported by thin client protocol. 

Description

There are changes needed for protocol, server side, and client side to support transactions.

Protocol changes

Add new operations to the thin client protocol:

NameCodeDescription
OP_TX_START4000Start a new transaction
OP_TX_END4001End the transaction

OP_TX_START message format

Request
byte

Concurrency control:

0 - OPTIMISTIC

1 - PESSIMISTIC

-1 - use server's default value

byte

Isolation level:

0 - READ_COMMITTED

1 - REPEATABLE_READ

2 - SERIALIZABLE

-1 - use server's default value

longTimeout (-1 - use server's default value)
intNumber of entries participating in transaction (may be approximate). 0 - default value.
stringlabel
Response

intUnique per client connection transaction id. This id should be returned as parameter with OP_TX_END message.

OP_TX_END message format

Request
int

Transaction id.

bool

Commit flag.


Empty response.

Server-side changes

As a first step, to support transaction from the server side 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.

Later, we can change the server-side implementation (no changes to the protocol or client-side implementations needed) to execute a transaction from the "client-connector" thread. This approach will be more effective since there will be no overhead to start additional threads. But before, we need to implement a mechanism to decouple transactions from the thread (when multiple transactions could be executed from the same thread). 

Client-side changes

Client implementation must review the logic of failover since we can't silently change servers in case of connection error in the middle of the transaction.

Proposed new interfaces for java thin client:

ClientTransactions
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 ClientTransactions withLabel(String lb);
}


ClientTransaction
public interface ClientTransaction extends AutoCloseable {
    public void commit();
    public void rollback();
    public void close();
}


Risks and Assumptions

Without decoupling transactions from the thread for each connection which starts transactions explicitly new dedicated thread will be added (we already have one dedicated NIO thread per client connection and also thread pool to process client messages) this will bring extra pressure to the server.

We can't support concurrent transactions per connection on the client side without fundamental changes to the current protocol (cache operation doesn't bound to transaction or thread and the server doesn't know which thread on the client side do this cache operation). So, now we can only support one active transaction per connection.

Discussion Links

http://apache-ignite-developers.2346864.n4.nabble.com/Thin-client-transactions-support-td27761.html

Reference Links

// Links to various reference documents, if applicable.

Tickets

key summary type created updated due assignee reporter priority status resolution

JQL and issue key arguments for this macro require at least one Jira application link to be configured

  • No labels