Developing Applications
Ivory |
Download Ivory |
Java Docs |
Service Cache
Creating Your Own Applications
Before creating your own applications and data structures, please
read about conits and
assumptions about their structure. Also, refer to the
Java docs for more information.
Guidelines for Data Structures:
- Java objects that will be replicated should extend either the ConitRoot or ConitObject class.
- References into conits can only be made through an object that is a subclass of ConitRoot.
- ConitRoot subclasses must implement "nullifyReferences" until
we have a bytecode transformer to handle adding the method.
This requires making all references null and is called
when evicting a conit from the cache.
- Any method that modifies the object must call "setDirty",
which is defined and handled in the ConitRoot class.
- Classes that extend ConitRoot should implement a subclass of the
Consistent
interface
that lists the methods that modify the object.
In other words, methods that require committing
or versioning should be prototyped in an interface
that extends the Consistent
interface.
Limitations:
- Using arrays and Java-defined collection classes
is not fully tested and debugged.
Using the API
Four methods defined in servicecache's StateManager
class are available to applications/data structures.
- Touch: Get updates for this object and its conit
if the object could be stale.
- Fault: When an application on a secondary node follows a
cross-conit reference to a conit that is not resident on that node,
the node faults and fetches that conit from the primary node,
which is usually the originating node.
- Commit: Push a conit's updates to the primary. If there is a conflict
with the primary, the conit is evicted. When the conit is next accessed,
the full conit is fetched from the primary.
- Evict: A conit can be thrown out of a cache. Only information
about conit roots is saved because other conits may only refer into a conit
through these objects.
These few operations allow applications to implement many different
policies for maintaining consistency.
Transforming Classes
After the data structures are compiled,
they should be transformed to use the Ivory infrastructure
through the API.
This transformation can be done by hand or using the
transformation classes that are in the xform
directory.
The xform
directory contains the script we used to
transform the test applications.
We plan to have a toolkit to simplify transformation in the near future.
The test applications use a combination of by-hand and
automatic transformation.
- All data structure classes should be transformed using the
AutoWriter
class.
This makes sure that the objects can be serialized and
replicated at other sites.
Guidelines for Applications:
Ivory can be used to ease development of other applications.
We believe that the only Ivory-related class that will need to be
modified is the StateManager
class.
Ivory has some hardcoded variables--such as
nextPullMillis
the time delay for pulling updates
- Synchronize properly. Ivory does not do
more synchronization than is necessary to
replicate and cache data so as not to
increase locking overhead.
Sara E. Sprenkle
Last modified: Sat Jun 2 15:58:13 EDT 2001