THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
...
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 |
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.
...
Also, the 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.
If client allowed to use several concurrent transactions per connection it must support async request sending to server, otherwise, deadlock is possible (for example, when the first transaction lock the key, then the second transaction try to lock the same key, blocks and lock the connection).
Proposed new interfaces for java thin client:
...
Overview
Content Tools
Apps