Implementing RMI Systems II EEE465 2001 Reference: CDK00 ch. 5

1
Implementing RMI Systems (II) EEE465
2001Reference CDK00 ch. 5

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Issues

• Defining what may be accessed remotely
• Object identity
• remote object identifiers
• Communications mechanism
• using stubs and skeletons
• Automatic marshalling and unmarshalling of
  arguments and return values
• for primitive types and objects
• Persistence
• activation and passivation
• Garbage collection
• Concurrency control and transactions

3
Persistence

• shared information must be long-lived, so that it
  survives even when no-one is working on it
• e.g., the ChatServer should still be available
  even with no clients
• ideally, server objects will
• survive system restarts
• be capable of being moved to secondary storage,
  when not currently active
• requirements
• persistent object store
• persistent object identifiers
• persistent objects (capable of being activated
  and passivated transparently)

4
Persistent Object Identifiers

• enough information to unambiguously locate an
  object in the store
• activation
• receive request for object from external source
  (e.g., name service) using OID
• map OID to POID, retrieve object, attach to OID
• passivation
• detect object no longer in use
• generate POID (pointer swizzling), and maintain
  mapping between OID and POID
• passivate object into store

5
Flattening and Unflattening

• objects must be flattened to put in the store
• similar to serialization for communication
• either
• coded on an object-by-object basis (C)
• done using a generic mechanism based on
  reflection
• reflection allows the attributes (e.g., its
  class, fields, etc.) of an object to be
  determined at run-time
• provided in Smalltalk, Java, some other languages
• important to ensure that each object is
  passivated exactly once (similar to serialization
  issue discussed yesterday)

6
What is Persistent?

• only new persistent objects, or objects whose
  values have changed, need to be passivated
• two strategies
• persistent object store maintains persistent
  root, and all objects reachable from the root are
  passivated (Java)
• allows garbage collection of unreachable objects
• persistent object store provides some classes on
  which persistence is based objects inheriting
  from those classes are passivated (C)

7
Garbage Collection

• objects take up space
• when an object is no longer referred to by any
  other objects, it is garbage and should be
  removed
• in languages with explicit memory allocation
  (e.g., C), the programmer must explicitly
  destroy objects before they go out of scope
• in languages with implicit memory allocation
  (e.g., Java), the system detects unreferenced
  objects and removes them automatically
• automatic removal of unreferenced objects called
  garbage collection

8
Techniques

• Common garbage collection techniques include
• reference counting
• each object includes a count of all other objects
  that reference it, which is incremented/decremente
  d automatically by system
• when count reaches zero, object removed
• problem circular references
• mark and sweep
• mark phase start from known accessible objects,
  follow accessibility graph, marking all reachable
  objects
• sweep phase sweep through the entire object
  space, removing all objects not marked as
  reachable
• problem disruptive
• Many other sophisticated techniques
• generation scavenging, etc.

9
Remote Garbage Collection

• Must also track all remote references
• In Java, capability built into JVM, handled along
  with regular garbage collection
• based on reference counting
• Must interact with persistence mechanism
• when persistent object no longer referenced,
  passivated rather than garbage collected
• Problem of partial failure
• remote client may fail without ever notifying
  local JVM
• handled using lease mechanism
• remote reference only active as long as lease is
  maintained
• when lease expires, reference assumed no longer
  valid

10
Concurrency Control

• Remotely accessible objects subject to
  unpredictable concurrent access patterns must be
  written with concurrent access in mind
• Simplest method enforce serial access using
  locks/monitors (Java synchronized)
• must guard against distributed deadlock
• In some cases, sequences of nested invocations
  must be atomic
• requires additional transaction mechanism
• provided by, e.g., relational databases, Jini,
  Enterprise Java Beans

11
Next ClassA Name Service Model