start page | rating of books | rating of authors | reviews | copyrights

Book Home Java Distributed Computing Search this book

C.2. Entry and EntryRep

Every JavaSpace consists solely of entries, which are represented by instances of the Entry class. An entry is a group of object references, which represent the fields in the Entry. When an entry is added to a JavaSpace, the entry is stored in serialized form by independently serializing each field in the Entry. Because of this, every field in an entry has to be public, has to be Serializable, and has to be an Object (not a primitive type).

EntryRep s act as the conduit for Entrys into and out of JavaSpaces. They serialize Entrys before going into a JavaSpace during a write operation, and de-serialize Entrys returned as the result of read, take, or notify operations. A given EntryRep can be written multiple times to the same JavaSpace, which would result in multiple identical entries in the space.

EntryReps are used to specify JavaSpace entries in read or take operations. A client creates an Entry with the values and wildcards that it wants to match in a JavaSpace. Then it wraps it in an EntryRep, which generates the serialized form of the template Entry and passes it to the JavaSpace as an argument of the operation. The JavaSpace compares the serialized bytes of the template Entry to its own Entrys, and matches on the first one whose serialized bytes are the same as those of the non-null fields in the template Entry.

Another benefit of serializing each field of an Entry independently is that it allows for fault-tolerant retrieval of entries from the space. If a read, take, or notify operation finds a match and an error occurs while deserializing it, an UnusableEntryException is thrown. The exception object contains a list of the fields from the entry that were successfully deserialized from the JavaSpace, along with a list of the unusable fields and a list of nested exceptions that explain why each unusable field failed to be deserialized. Some reasons for failed deserialization are missing class files on the client, or a RemoteException caused by a remote reference on the Entry that isn't valid any more. Your client can react in different ways to an UnusableEntryException: it can try to use the partial entry that it received, it can ignore the partial entry and try to read or take another entry, or it can give up altogether.

The authors of the JavaSpaces specification make a point of mentioning that, since at this time the Java API doesn't support persistent server objects, it's dangerous to put remote references into a JavaSpace as part of an Entry. If the server object behind the remote reference is destroyed for some reason (e.g., server restart, server crash, etc.), then the remote reference becomes invalid; however, this won't be discovered until a client tries to get the entry from the JavaSpace. The authors suggest that you use metadata about the remote object, namely its remote host and registry name, in the Entry, and let the client establish its own remote reference to the server object.



Library Navigation Links

Copyright © 2001 O'Reilly & Associates. All rights reserved.