|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
See:
Description
Class Summary | |
AID | Represents the identity of a JDO object in the File/Object store. |
Block | Represents an object stored in the database as a semi-opaque value. |
DBClass | Represents a class stored in the database. |
DBExtent | Represents a set of instances of a given class stored in the database. |
DBInfo | This class represents the information about the contents of the store itself which must be durable across JVMs. |
Dumper | Provides information such as metadata, extents, objects about the store. |
FOStoreBtreeStorage | FOStore specific BtreeStorage subclass. |
FOStoreConnectionFactory | A connection factory for FOStore. |
FOStorePM | Subclass of #PersistenceManagerImpl implementing
abstract methods newQuery . |
FOStorePMF | The File/Object Store's implementation of a PersistenceManagerFactory. |
FOStorePMFFactory | Creates a FOStorePMF when read in via JNDI. |
FOStoreRemoteConnection | Represents a connection to a store that runs in a JVM separate from that of a client. |
Main | Standalone server for FOStore databases. |
OID | Represents the identity of a JDO object in the File/Object store. |
SubclassSet | Represents a set of CLIDs of subclasses of a given class. |
Exception Summary | |
FOStoreFatalInternalException | This is an exception which _should_ never be thrown, as it indicates an error in the implementation, such as a bug that has been found. |
FOStoreFatalIOException | This is an exception which _should_ never be thrown, as it indicates an error in I/O traffic between client and server. |
FOStoreLoginException | This is an exception which _should_ never be thrown, as it indicates an error in the implementation, such as a bug that has been found. |
This package contains the implementation of the File/Object Store JDO Reference Implementation (FOStore, pronounced "foster").
This file provides information for implementors and maintainers of the package.
All objects created by the client have a datastore-provided ID, called an Object Id (OID.java). Part of the OID represents the class of the object; these id's are called Class Id's and are separately managed (CLID.java). When an object is made persistent:
Employee emp = new Employee("John Doe", 12345);PersistenceManager pm = PersistenceManagerFactory.getPersistenceManager();pm.makePersistent(emp);
the object is assigned a "provisional" OID, assigned by the client, not by the datastore. When a real OID is required (getObjectId) or the transaction commits, the user's object is then flushed to the store, and a real ID is provided. The datastore provides a datastore ID corresponding to the provisional ID.
The mapping from provisional to real id's is maintained by both the client and the store. The client maintains it on a per-PMF basis (in FOStorePMF.java). The store maintains it for all clients (currently a single map, which is incorrect as it should be per-client; see FOStoreDatabase.java).
Similar tables are kept, separately, for CLIDs. These tables are in FOStoreModel.java on the client side, and in FOStoreDatabase.java on the store side. Recall that the OID of an object contains the CLID of the class of the object. If no instances of that class have yet been stored, then the OID contains a provisional CLID. The process of storing the object also stores a representation of the object's class, and creates a datastore-provided CLID.
The need for each of the tables is as follows:
OID, client: Assume a persistent object is created, and put into a persistent graph structure. Assume further that the object is comitted, but not the graph structure. At that point, the graph still refers to the object by its provisional OID. Having this table allows us to find the real object ID.
OID, store: Assume a graph structure of new objects is to be stored, in which a single object is referenced more than once. Each time it is referenced, it is with the provisional ID assigned by the client. The store must ensure that an object is only assigned a single datastore ID, and this table ensures that.
CLID, client: StoreManager implementations are required to be able to provide a java.lang.Class given an OID. When assigning OIDs, FOStore will never use a provisional CLID if the datastore-provided CLID is available. However, it is possible that two objects of the same class are created, and one is stored. The CLID table in FOStoreMetaData will, after the store, only the datastore-provided ID. If one then asks the store manager for the class of the unstored object by it's OID, we still have to provide the right answer. By keeping a mapping of provisional IDs to datastore IDs in this table, we can do so.
CLID, store: Exactly the same reasoning as for the OID table in the store: ensuring that a given class is only ever assigned a single CLID.
Objects are stored in the database by way of InsertRequest, and fetched by way of FetchRequest. Each contains several methods to store and fetch Java types. If in the unlikely event that more primitive types are added to Java, they will have to be added here. Also, support will have to be added to FieldManager, which is outside of FOStore in the common package, and to it's implementation in the fostore package, in AbstractFieldManager
More likely, however, is the need to extend the set of non-primitive types, such as Collection types, that FOStore supports. Support for these lies in 2 files: CLID.java and the various XXXTranscriber.java files. The first keeps a table of "known" CLID's, which maps between a java.lang.Class and a compiletime-fixed CLID. The latter has a Transcriber class for each of the known CLID's, for instance LocaleTranscriber writes and reads java.util.Locale objects to/from I/O streams.
|
||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |