*

Overview Of filepobc

  • Overview Of filepobc.test - filepobc.test tests filepobc and lrucmgr
  • Overview Of bcfw - filepobc and lrucmgr use these interfaces
  • Overview Of lrucmgr - filepobc uses lrucmgr
  • Overview of filepobc emit.
  • Prereqs

    The filepobc requires the following other packages:

    Goals

    One goal is to provide an example BaseCollection implementation for the more serious servers to use when planning and implementing support for the mofw extension to java within their server. It supports finite memory/backingstore resources because this is a must for such servers. One reason it is programmed strictly in java is to be easy to quickly understand.

    Another goal is to provide a reasonably robust and efficient persistence mechanism that can be part of Bojangles that everyone can readily use. It prereq nothing. It was written using the java File and RandomAccessFile classes for this reason.

    Design Point

    The FilepoBC adopts the design point described in the bcfw Overview. That is, it does not attempt to implement a new persistence or indexing mechanism. Instead, it simply wrappers those mechanisms that already exist in Unix-like file systems, so that they are available for objects.

    The FilepoBC uses Unix-like file systems for persistence. These systems have an index mechanism per directory that maps names to uninterpreted byte-stream (Blob) files. Each instance of FilepoBC has a single directory whose path name is part of its EssentialData, and puts each Managed object's state in a separate file. FilepoBC provides no additional indexing mechanism. This means that FilepoBC inherits the characteristics of these file systems, including the sophistication of its directory index, its robustness (journaled metadata), its storage overhead per file, its performance characteristics, etc. Client operating systems typically provide less sophistocated techniques in their directory implementation than do server operating systems (eg, sequential vs. B-tree lookup), because they have different design points. If an instance of FilepoBC is run on a client vs. server operating system, it will have correspondingly different performance characteristics.

    If the application needs different characteristics than those provided by FilepoBC, then a different BaseCollection implementation should be chosen. For example, if many small objects are needed in a BaseCollection, then a BaseCollection that wrappers a record file system or database should be chosen.

    Description of FilepoBC

    FilepoBC is a BaseCollection that stores its Managed object's state in a file system such as in AIX, NT, OS/2, Win95, etc. A FilepoBC instance gives each of its Managed objects a separate file in the same directory. The path name of this directory is part of the FilepoBC's EssentialData.

    FilepoBC is an implementation of the BaseCollectionEC interface, which means that it uses an external CacheManager (the LruCacheManager) to cache its Cached objects. A single instance of LruCacheManager can cache Cache objects for multiple instances of FilepoBC or any other BaseCollectionEC.

    FilepoBC is packaged as a Manageable, so that an AA can either manage it manually or assemble it into a Managed whose instances can be managed by another BaseCollection. FilepoBC is the interface name and FilepoBCImpl is the implementation class name. FilepoBC supports the optional Dependent interface because, during its activation, it needs to get its cache manager and the dependent context for its Managed objects. FilepoBC supports the optional IdentityDelegator interface because it exports references to itself as a return parameter in some of its methods.

    An instance of a FilepoBCImpl can be either of the following:

    A FilepoBCImpl is made homogeneous if its homogeneous Managed class EssentialData is not null. Otherwise, it is heterogeneous. Handling the homogeneous case is important because most Managed objects will belong to a homogeneous BaseCollection, and this homogeneous case has a significant optimization.

    FilepoBC has two objects at runtime for each activated Managed object that are instances of ManagedDel and FilepoCached. An instance of ManagedDel object is a skinny object that implements the ManagedDel interface and delegates the Manageable interface methods to a FilepoBC Cached object. To avoid having to store multiple class names for these, a FilepoBCImpl expects the AA to form these two class names by appending a managedSuffix (eg, FilepoManaged) and cachedSuffix (eg, FilepoCached) onto the interface name (eg, <package name>.Employee).

    The interface name is determined as follows:

    The interface name is what is remembered in either case, so the Managed and Cached class names can be quickly obtained by appending the managedSuffix and cachedSuffix. If these are not found during runtime, FilepoBC throws a FilepoClassNotFoundError.

    The managedSuffix and cachedSuffix are part of the EssentialData of a FilepoBC instance.

    The AA prepares these two classes as follows: