*

Overview Of bcfw

  • Overview Of lrucmgr - filepobc and lrucmgr use these interfaces
  • Overview Of filepobc - filepobc uses bcfw
  • Overview Of filepobc.test - filepobc.test tests filepobc and lrucmgr
  • This is a framework so there is no test subdirectory. Testing for this is in COM.ibm.jaws.services.filepobc.test.

    Design Point For BaseCollections

    We think that most BaseCollections should be wrappers around an exiting database system, file system or OODB. To support robust collections of objects whose state and identifiers are persistent, there is no reason to reimplement plumbing code that already works well and is generally available. The mofw goal is to provide a standard interface contract between OO application developers and services so that code reuse (and therefore value) is increased on both sides of the contract. Such a standard permits object support using a straight forward wrappering of existing storage systems.

    Sometimes you hear talk about storage access patterns for object applications. This is a myth invented by myself and my colleagues during a past life when we were trying to sell OODBs. It makes about as much sense as talking about access patterns for procedural applications. Implementing an application using either object or procedural techniques does not change its storage access patterns. Most OLTP applications need efficient random rifle-shot access and update, as well as robust servers, because that is what these applications do and what they need, regardless of whether they are implemented with object or procedural techniques. An application that needs heavy traversal through data, or efficient queries or robust identifiers for its entities or whatever, then these do not change if object techniques are used to implement it. If a storage system fills an important market in the procedural world, then it will fill that same market in the world of objects.

    Wrappering these servers is a sensible way to support objects because:

    Description of Interfaces

    This framework is for BaseCollection service providers, not for BaseCollection clients.

    The following conventions allow BaseCollection providers provide common functions in a similar way to simplify the AA job:

    The following interfaces are introduced to help BaseCollection providers provide caching BaseCollections and cache managers that can be mixed and matched:

    These BaseCollectionDel, BaseCollectionEC and CacheManager interfaces are not seen by the BaseCollection client. They are for cooperation between the implementation objects.

    The Syncable interface is introduced to allow a BaseCollection or Managed client to ensure that these objects are consistent with their stable storage.