Modify

Ticket #157 (closed enhancement: fixed)

Opened 9 years ago

Last modified 8 years ago

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:1 Changed 8 years ago by hauma

  • Version set to 1.07h
  • Milestone changed from 1.08a to 2.00

comment:2 Changed 8 years ago by hauma

For historical research: This feature was initially implemented in changeset:1783.

View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.