You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the cases where you do not need to colocate computations with data but simply want to process all data remotely, you can run local cache queries inside the `call()` method. Consider the following example.
313
-
314
-
Let's say we have a cache that stores information about persons and we want to calculate the average age of all persons. One way to accomplish this is to run a link:key-value-api/using-cache-queries[scan query] that will fetch the ages of all persons to the local node, where you can calculate the average age.
315
-
316
-
A more efficient way, however, is to avoid network calls to other nodes by running the query locally on each remote node and aggregating the result on the local node.
Note that the scan query is executed in the local mode. It means that it will only fetch objects from the Person cache that are stored localy and will not request data from other nodes.
308
+
=== Processing Cache Data Locally
346
309
347
-
If you broadcast this task to all nodes, all person objecs will be processed (each locally), and the results are sent to the node that initiated the task.
The task is executed on every node, where it will query all persons stored locally and calculate the local average. Then the result are sent to the node that initiated the task and summed up. In this implementation, objects are not transferred via network.
310
+
If you need to process all cache data remotely, you can broadcast a task to the data nodes and run a local cache query inside the task.
311
+
In this mode, each node scans only the cache entries stored locally, processes them there, and returns only the aggregated result to the caller.
358
312
313
+
For example, assume that a cache stores `Person` objects and it is necessary to calculate the average age of all persons.
314
+
A regular link:key-value-api/using-cache-queries[scan query] transfers matching entries to the query initiator page by page.
315
+
The following example avoids transferring the full dataset over the network: the task is broadcast to the nodes that store data for the `person` cache, and each node runs `ScanQuery.setLocal(true)`.
316
+
The task checks primary ownership so backup copies are not counted twice.
Copy file name to clipboardExpand all lines: docs/_docs/key-value-api/transactions.adoc
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -92,10 +92,10 @@ It is critical that an Ignite Transaction should be `closed` regardless of its c
92
92
93
93
== Transaction Savepoints
94
94
95
-
Savepoints allow you to mark an intermediate state inside an explicit transaction and later roll back only the changes made after that point.
95
+
Savepoints allow you to mark an intermediate state inside a transaction and later roll back only the changes made after that point.
96
96
They are useful when a transaction contains several logical steps and one of the later steps can be discarded without rolling back the whole transaction.
97
97
98
-
Ignite supports savepoints only for explicit `PESSIMISTIC` transactions.
98
+
Ignite supports savepoints only for explicit transactions.
99
99
Savepoints are local to the transaction that created them and are removed when the transaction is committed or rolled back.
100
100
101
101
Use `Transaction.savepoint(name)` to create a savepoint.
0 commit comments