THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
...
| ID | IEP-34 | ||||||||
| Author | |||||||||
| Sponsor | |||||||||
| Created |
| ||||||||
| Status |
|
| Table of Contents |
|---|
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:
| Name | Code | Description |
|---|---|---|
| OP_TX_START | 4000 | Start a new transaction |
| OP_TX_END | 4001 | End the transaction |
OP_TX_START message format
| Request | |
|---|---|
| byte | Concurrency control: 0 - OPTIMISTIC 1 - PESSIMISTIC |
| byte | Isolation level: 0 - READ_COMMITTED 1 - REPEATABLE_READ 2 - SERIALIZABLE |
| long | Timeout |
| string | label |
...
| Response | |
|---|---|
| int | Unique per client connection transaction id. This id should be returned as parameter with OP_TX_END message and all messages of cache operations within the transaction. |
OP_TX_END message format
| Request | |
|---|---|
| int | Transaction id. |
| bool | Commit flag. |
Empty response.
Cache operations
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.
...
| 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) | modified |
| int | Transaction id (present only if "under transaction" flag is set, i.e. if flags & 0x02 != 0) | added |
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.
...
When the client sends OP_TX_END request, thread served this request resumes the transaction and commit or rollback it.
Client-side changes
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.
...
This transaction configuration can be used when the client connection is created (as a property of ClientConfiguration class).
Risks and Assumptions
//
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
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
Content Tools
Apps