...
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 |
long | Timeout (-1 - use server's default value) |
int | Number of entries participating in transaction (may be approximate). 0 - default value. |
string | label |
Response | |
---|---|
int | Unique per client connection transaction id. This id should be returned as parameter with OP_TX_END message. |
...
Request | |
---|---|
int | Transaction id. |
bool | Commit flag. |
Empty response.
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).
We need to add a new field to requests header of all cache data manipulation operations (opcodes 1000-1020, 2000, 2002, 2004) to bind these operations with the transaction.
We also can remove deprecated "flag" field in this protocol version. "Flag" field is only used by OP_QUERY_SCAN operation. So, we need to add a new field "keepBinary" to OP_QUERY_SCAN request.
Proposed changes to cache operations request header format:
Type | Description | |
---|---|---|
int | Length of payload | |
short | Operation code | |
long | Request id | |
int | Cache id | |
removed | ||
int | Transaction id (0 if there is no explicitly started transaction) | added |
Proposed changes to OP_QUERY_SCAN request format:
Type | Description | |
---|---|---|
Header | Cache operation request header | |
bool | Keep binary | added |
Data Object | Filter object. Can be null if you are not going to filter data on the cluster. The filter class has to be added to the classpath of the server nodes | |
byte | Filter platform: JAVA = 1 DOTNET = 2 CPP = 3 | |
int | Cursor page size | |
int | Number of partitions to query (negative to query entire cache) | |
bool | Local flag - whether this query should be executed on local node only |
On the server side, we need to have the ability to decouple transactions from threads. We can do this by using transaction suspend/resume methods. Suspend/resume methods are only implemented for optimistic transactions now, so we need to implement this mechanism for pessimistic transactions first.
Using this approach there is no need to start any new thread to serve the transaction. All transaction control operations and all cache operations within transactions will be served by existing "client-connector" threads.
When the client sends OP_TX_START request, a new transaction is starting in a suspended state.
When the client performs a cache operation within a transaction, thread served this request resumes the transaction, processes cache operation and suspends the transaction again.
When the client sends OP_TX_END request, thread served this request resumes the transaction and commit or rollback it.
The client must bind transaction and all cache operations which was made within this explicitly started transaction. We can implement transaction per thread approach on the thin client side as implemented now for the thick client. In this case, each transaction on the thin client side will be bound to a thread started this transaction. And each cache operation performed by this thread will be bound to the same transaction until the transaction is completed.
Also, the client 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.
...
Code Block | ||||
---|---|---|---|---|
| ||||
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);
} |
...
Code Block | ||||
---|---|---|---|---|
| ||||
public interface ClientTransaction extends AutoCloseable { public void commit(); public void rollback(); public void close(); } |
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.//
http://apache-ignite-developers.2346864.n4.nabble.com/Thin-client-transactions-support-td27761.html
...