Ticket #157 (closed enhancement: fixed)
Replicated objects with collective update
| Reported by: | Bernhard Haumacher (haui at haumacher dot de) | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 2.0 |
| Component: | uka.karo | Version: | 1.07h |
| Severity: | normal | Keywords: | |
| Cc: |
Description
Besides regular remote objects, KaRMI now supports replicated objects. A replicated object is created concurrently on a specified set of virtual machines. Creation of a replicated object is issued on a single node and results in a reference to the local replica of the created replicated object. To make the newly created replicated object programmatically known to other nodes, its local replica is passed in remote method invocations. On the remote node, parameters representing replicas on the sending side are resolved to their corresponding local replica on node executing the remote method call. Other than remote objects, replicated objects are always locally available and represented by their local replica. There are no remote invocations on replicated objects, only local regular Java method calls on their local replicas. There are two ways, a replicated object can be used. The first way is exclusive update with possibly multiple observers. In this mode, the replicated object is locked as a whole, updated locally, and the modifications are distributed to all replicas during an exclusive update. The second was is the collective update with multiple concurrent writers. In this mode there have to be as many participating threads as replicas exist for the replicated object. Each thread acquires a lock on its local replica, updates a partition of its state and performs a collective update which merges all changes made by all thread and makes them available at all replicas.
See also
ticket:156, ticket:177, ticket:179
implemented since 1.08a.
Attachments
Change History
comment:2 Changed 8 years ago by hauma
For historical research: This feature was initially implemented in changeset:1783.
