...
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) |
string | label |
Response | |
---|---|
int | Unique per client connection transaction id. This id should be returned as parameter with OP_TX_END message. |
...
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 | |
byte | flags (new "under transaction" flag with bitmask 0x02 introduced, to indicate that operation performed under transaction) | modifiedremoved |
int | Transaction id (0 if there is no explicitly started transaction) | added |
Proposed changes to OP_QUERY_SCAN request format:
present only if "under transaction" flag is set, i.e. if flags & 0x02 != 0) | added | 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 |
Server-side changes
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.
...
Code Block | ||||
---|---|---|---|---|
| ||||
public interface ClientTransactions { public ClientTransaction txStart(); // Start tx with client default values of concurrency, isolation and timeout properties. public ClientTransaction txStart(TransactionConcurrency concurrency, TransactionIsolation isolation); // Start tx with default timeout. public ClientTransaction txStart(TransactionConcurrency concurrency, TransactionIsolation isolation, long timeout); public ClientTransactions withLabel(String lb); } |
...
Code Block | ||||
---|---|---|---|---|
| ||||
public interface ClientTransaction extends AutoCloseable { public void commit(); public void rollback(); public void close(); } |
To configure client default concurrency, isolation and timeout values for connection it is proposed to create new configuration class:
Code Block | ||||
---|---|---|---|---|
| ||||
public class ClientTransactionConfiguration {
public static final TransactionConcurrency DFLT_TX_CONCURRENCY = TransactionConcurrency.PESSIMISTIC;
public static final TransactionIsolation DFLT_TX_ISOLATION = TransactionIsolation.REPEATABLE_READ;
public static final long DFLT_TRANSACTION_TIMEOUT = 0;
public TransactionConcurrency getDefaultTxConcurrency();
public ClientTransactionConfiguration setDefaultTxConcurrency(TransactionConcurrency dfltConcurrency)
public TransactionIsolation getDefaultTxIsolation();
public ClientTransactionConfiguration setDefaultTxIsolation(TransactionIsolation dfltIsolation);
public long getDefaultTxTimeout();
public ClientTransactionConfiguration setDefaultTxTimeout(long dfltTxTimeout);
} |
This transaction configuration can be used when the client connection is created (as a property of ClientConfiguration class).
//
...