...
- Transaction belongs to a specific node and client connection. When a non-null transaction is provided by the user, partition awareness logic is skipped.
Protocol Changes
Add
new op to get partition assignment for a table- Add response flag to track assignment changes
PARTITION_ASSIGNMENT_GET operation
Response |
---|
array | Array of node ids, where array index is the partition number |
Update standard response message to include flags
Response |
int | Type = 0 |
int | Request id |
int | Flags |
int | Error code (0 for success) |
string | Error message (when error code is not 0) |
... | Operation-specific data |
- Include colocation flag in SCHEMAS_GET response.Include ColocationKeys into ClientSchema
Tracking Assignment Changes
...
- Response flag. All server responses include flags field, and server sets a flag when the assignment has changed since the last response. It is up to the client to retrieve updated assignment when needed. This mechanism is used in Ignite 2.x.
Pros: Low overhead, no extra network traffic.
Cons: Idle clients do not get the update.
- Server → client notification. As soon as assignment changes, server sends a message to all clients.
Pros: Immediate update for all clients.
Cons: Increased network traffic and server load. Some clients may not need the update at all (not all APIs require this).
- PrimaryReplicaMissException (suggested in
Jira |
---|
server | ASF JIRA |
---|
serverId | 5aa69414-a9e9-3523-82ec-879b028fb15b |
---|
key | IGNITE-17394 |
---|
|
comments).
Pros: No protocol changes.
Cons: Retry is required on replica miss (complicated & inefficient). Using exceptions for control flow.
First The first approach is battle tested and seems to be the most optimal.
...