IBM TSpaces User's Guide

The model is simple. There are clients and there are servers.

// Create the initial tuplespace
Tuplespace ts = new Tuplespace(  spaceName, serverName);
// Write some data, tagged "mydata1"
ts.write("mydata1", dataInstance);

// Read the specific data record
resultTuple = ts.read("mydata1", DataInstance);
// Read ALL the records of that type
resultTupleSet = ts.scan(String, DataInstance);

In this section we briefly discuss the basics of TSpaces.

The client interface is very simple. A client creates an instance of a tuplespace, then uses the methods of that instance to read and write tuples. Tuples are just Java vectors of fields, which are basically type/value pairs.

3.1.1 Field class

The Field class is the most basic component of the Tuplespace data structure hierarchy. A field contains:

• Type
• Value
• Field Name (optional): Specifying a field name implies that this field will be indexed (and searched).

3.1.2 Tuple class

A Tuple is a vector of Fields.

The SuperTuple class is where the interesting functionality of tuples is implemented, but it's an abstract class, so clients should use either the Tuple or the SubclassableTuple.

Communication --- the communication protocol used between the client and server and the communication interface on both the client and the server

The client and server communicate with Sockets and ObjectStreams.

3.2.1 TupleSpace class

The TupleSpace Class is the main structure for attaching to the tuplespace community. It is the TupleSpace methods that an application uses to send and receive tuples from the shared network repository.

A TSpaces server contains many Tuplespaces -- potentially billions. It is up to the application writer to decide whether to use one or many tuplespaces for a particular application. However, it is important to know that it's really hard to run out of spaces, so there's no reason to try to fit too many different tuple types into a single space.

3.2.2 TupleSpace constructors

3.2.3 TupleSpace methods

Interesting ones: write, read, take, waitToRead, waitToTake, scan, consumingScan, count, countN, delete, deleteAll, and Rhonda.

3.3.1 Command Control Flow

The TSpaces server is composed of two main layers. The bottom layer comprises the basic tuple management. This is where tuple sets are stored, updated, indexed and scanned. The interface to this layer is the Tuple Management API. The top layer comprises the operator component, which is responsible for operator registration and handler, the implementation of an operator, management.

To execute a regular operator, such as read, the server performs the following steps:

• The Top Level Command Handler reads the incoming message and dispatches the appropriate operator lookup mechanism.
• The operator lookup checks the operator registry to see if the operator is valid (it is defined with an associated handler), then, assuming it is valid, locates the proper handler.
• The Command Handler launches the operator handler, with the original client message as the input.
• The operator handler executes, then returns an answer (if one is expected) to the Command Handler.
• The Command Handler returns to the client.

In more specific terms, here's what happens:

• The main server class, TSServer accepts connection from client, creates a TSIOHandler and passes off the socket (and goes back to listening for connections).
• The main connection class, TSIOHandler creates a TSDispatch object for the command, and waits for a response from the TSDispatch.
• TSDispatch locates the TupleSpace referenced by the client message. The TupleSpace (specifically "TS" in Java Class language) has associated with it a database manager (TSDB). The specific command sent by the client has associated with it an operator family, which translates to an operator handler factory, (TSFactory).
• TSFactory locates the the specific instance of TSHandler (which is an interface) for the operator, hands the handler to TSDispatch, who invokes the handler to execute the operator. The results of the handler are passed back to TSIOHandler, who then sends the answer back to the client.

3.3.2 Blocking Commands

When an application issues a WaitToRead or WaitToTake call, and the data is not yet there on the server, the application blocks on the call until an answer is returned. When a tuple arrives on the server that matches the Read or Take query, it is sent to the client and the application resumes.

Although the easy way to implement this would be to allocate a thread on the server for each user connection (which is what we did in our initial prototype implementation), this results in far too many threads when there are several outstanding application requrests. Therefore, under the covers, TSpaces uses a callback mechanism to contact the client when a tuple matching the outstanding query is present. That way, we do not need to keep the server thread suspended. And, unlike SUN's Javaspaces who also use notification, we lock the tuple before issuing the callback so that the user is guaranteed of getting the tuple when receiving the callback.

3.3.3 Persistence

There are two planned implementations of the tuple database. The memory-resident database (Light TSpaces) uses simple file-level persistence for tuples and indexes. The heavy-weight solution is to use IBM's DB2 (Deep TSpaces) as the main store. With DB2, we get an industrial grade transaction-based repository with inifinite storage capability. Currently, only the file-level persistence is supported.

3.3.4 Access Control

Access control is on a TupleSpace level; each operation defined on a TupleSpace has an associated list of AccessAttributes that must be satisfied by any client trying to execute that operation. For example, the take operation has Read and Write AccessAttributes, and the addHandler operation has the Admin AccessAttribute.

Light TSpaces employes a memory-resident database system for managing the tuples. The internal structures of this memory-resident database system are direct descendents from the Starburst Main Memory Manager [Starburst 92]. And, along with the tuple management, there are the Starburst indexes as well. The T Tree index [Lehman 86a, Lehman 86b] and the Modified Linear Hash index structures are used as well for general index search. The T Tree has gone through some modifications to allow both regular (single and multi-attribute, unique and non-unique) indexing and inverted text indexing.

• [Carriero 84] Nicholas Carriero, David Gelernter: Linda in Context. CACM 32(4): 444-458 (1984)
• [Gelernter 82] David Gelernter, Arthur J. Bernstein: Distributed Communication via Global Buffer. PODC 1982: 10-18
• [Gelernter 84] David Gelernter: A Note on Systems Programming in Concurrent Prolog. SLP 1984: 76-82
• [Gelernter 85] David Gelernter: Generative Communication in Linda. TOPLAS 7(1): 80-112 (1985)
• [Lehman 86a] Tobin J. Lehman, Michael J. Carey: Query Processing in Main Memory Database Management Systems. SIGMOD Conference 1986: 239-250
• [Lehman 86b] Tobin J. Lehman, Michael J. Carey: A Study of Index Structures for Main Memory Database Management Systems. VLDB 1986: 294-303
• [Starburst 92] Tobin J. Lehman, Eugene J. Shekita, Luis-Felipe Cabrera: An Evaluation of Starburst's Memory Resident Storage Component. TKDE 4(6): 555-566 (1992)