Home » db-derby-10.5.3.0 » org.apache.derby.iapi.services.monitor » [javadoc | source]
org.apache.derby.iapi.services.monitor
public class: Monitor [javadoc | source]
java.lang.Object
   org.apache.derby.iapi.services.monitor.Monitor

Services
A service is a collection of modules that combine to provide the full functionality defined by the service. A service is defined by three pieces of information:

  1. A fully qualified java class name that identifies the functionality or API that the service must provide. Typically this class represents a java interface. This class name is termed the factory interface.
  2. The identifier of the service. Services are identified by a String, this may be hard-coded, come from a UUID or any other source.
  3. An optional java.util.Properties set.

The running functionality of the service is provided by a module that implements the factory interface. The identifier of the this module is not (need not be) the same as the identifier of the service. The identifier of the service is held by the monitor in its service tables.
Each module in a service is keyed by at least one factory interface, identifier} pair. This pair is guaranteed to be unique within the service.
The lifetime of a module in a service is no longer than the lifetime of the service. Thus shutting down a service shuts down all the modules within a service. Optionally - an individual module within a service may be shutdown, this will in turn shutdown any modules it started if those module are not in use by other modules within the service. This would be handled by the monitor, not the module itself.
A service may be persistent, it goes through a boot in create mode, and subsequently boot in non-create mode, or a non-peristent service, it always boots in non-create mode. Persistent services can store their re-start parameters in their properties set, the monitor provides the persistent storage of the properties set. Non-persistent services do not have a properties set.

Booting Services
Services can be booted a number of ways

Any or all of these three latter methods can be implemented. A first release may just implement the look for all services and boot them. .

System Service
A special service exists, the System Service. This service has no factory interface, no identifier and no Properties set. It allows modules to be started that are required by another service (or the monitor itself) but are not fundamentally part of the service. Modules within this service are unidentified. Typically these modules are system wide types of functionality like streams, uuid creation etc.
The lifetime of a system module is the lifetime of the monitor. Optionally - this could be changed to reference count on individual modules, requires some minor api changes.

Modules
A module is found or booted using four pieces of information:

  1. The service the module lives in or will live in.
  2. A fully qualified java class name that identifies the functionality or API that the module must provide. Typically this class represents a java interface. This class name is termed the factory interface.
  3. The identifier of the module. Modules are identified by a String, this may be null, be hard-coded, come from a UUID or any other source. If the identifier is null then the module is described as unidentified.
  4. Boot time only - A java.util.Properties set. This Properties set is service wide and typically contains parameters used to determine module implementation or runtime behaviour.

The service is identified by explicitly identifiying the System Service or by providing a reference to a module that already exists with the required service.
The factory interface is provided by a String constant of the form class.MODULE from the required interface.
The module identifier is provided in a fashion determined by the code, in most cases a unidentified module will suffice.
The Properties set is also determined in a fashion determined by the code at create or add service time.

Module Implementations
When creating an instance of a module, an implementation is found through lists of potential implementations.
A list of potential implementations is obtained from a Properties set. Any property within this set that is of the form

derby.module.tag=java class name
is seen by the monitor as a possible implementation. tag has no meaning within the monitor, it is only there to provide uniqueness within the properties file. Typically the tag is to provide some description for human readers of the properties file, e.g. derby.module.lockManager for an implementation of a lock manager.
The monitor looks through four properties sets for lists of potential implementations in this order.
  1. The properties set of the service (i.e. that passed into Monitor.createPersistentService() or Monitor.startService()).
  2. The System (JVM) properties set (i.e. java.lang.System.getProperties()).
  3. The application properties set (i.e. obtained from the derby.properties file).
  4. The default implementation properties set (i.e. obtained from the /org/apache/derby/modules.properties resource).
Any one of the properties can be missing or not have any implementations listed within it.
Every request to create an instance of a module searches the four implementation lists in the order above. Which list the current running code or the passed in service module came from is not relevant.
Within each list of potential implementations the search is conducted as follows:
  1. Attempt to load the class, if the class cannot be loaded skip to the next potential implementation.
  2. See if the factory interface is assignable from the class (isAssignableFrom() method of java.lang.Class), if not skip to the next potential implementation.
  3. See if an instance of the class can be created without any exceptions (newInstance() method of java.lang.Class), if not skip to the next potential implementation.
  4. [boot time only] See if the canSupport() method of ModuleControl returns true when called with the Properties set of the service, if not skip to the next potential implementation.
If all these checks pass then the instance is a valid implementation and its boot() method of ModuleControl is called to activate it. Note that the search order within the list obtained from a Properties set is not guaranteed.

Module Searching
When searching for a module the search space is always restricted to a single service. This service is usually the system service or the service of the module making the search request. It would be very rare (wrong?) to search for a module in a service that was not the current service and not the system service.
Within the list of modules in the service the search is conducted as follows:

  1. See if the instance of the module an instance of the factory interface (isInstance() method of java.lang.Class), if not skip to the next module.
  2. See if the identifier of the module matches the required identifier, if not skip to the next module.
  3. See if the canSupport() method of ModuleControl returns true when called with the Properties set of the service, if not skip to the next module.
Note that no search order of the modules is guaranteed.
Also note that a module may be found by a different factory interface to the one it was created under. Thus a class may implement multiple factory interfaces, its boot method has no knowledge of which factory interface it was requested by.

Service Properties
Within the service's Properties a module may search for its parameters. It identifies its parameters using a unqiue parameter name and its identifier.
Unique parameter names are made unique through the 'dot' convention of Properties files. A module protocol picks some unique key portion to start, e.g. RawStore for the RawStoreFactory and then extends that for specific parameters, e.g. RawStore.PageSize. Thus parameters that are typically understood by all implementations of that protocol would start with that key portion. Parameters for specific implementations add another key portion onto the protocol key portion, e.g. RawStore.FileSystem for an file system implementation of the raw store, with a specific parameter being RawStore.FileSystem.SectorSize.
These are general guidelines, UUID's could be used as the properties keys but would make the parameters hard to read.
When a module is unidentified it should look for a parameter using just the property key for that parameter, e.g. getProperty("RawStore.PageSize").
When a module has an identifier is should look for a property using the key with a dot and the identifier appended, e.g. getProperty("RawStore.PageSize" + "." + identifier).
In addition to searching for parameters in the service properties set, the system and application set may be searched using the getProperty() method of ModuleFactory.
Should any order be defined for this, should it be automatic?
Field Summary
public static final  String SERVICE_TYPE_DIRECTORY     
public static final  Object syncMe     
public static final  String NEW_INSTANCE_FROM_ID_TRACE_DEBUG_FLAG    Global debug flag to turn on tracing of reads calls newInstanceFromIdentifier() 
public static final  String DEBUG_TRUE     
public static final  String DEBUG_FALSE     
Constructor:
 public Monitor() 
Method from org.apache.derby.iapi.services.monitor.Monitor Summary:
bootServiceModule,   bootServiceModule,   classFromIdentifier,   clearMonitor,   createPersistentService,   exceptionStartingModule,   findService,   findServiceModule,   findSystemModule,   getEngineType,   getLocaleFromString,   getMonitor,   getMonitorLite,   getServiceModule,   getServiceName,   getStream,   getSystemModule,   isDesiredCreateType,   isDesiredType,   isDesiredType,   isFullUpgrade,   logMessage,   logTextMessage,   logTextMessage,   logTextMessage,   logTextMessage,   logTextMessage,   logThrowable,   missingImplementation,   missingProductVersion,   newInstanceFromIdentifier,   removePersistentService,   setMonitor,   startMonitor,   startNonPersistentService,   startPersistentService,   startSystemModule
Methods from java.lang.Object:
clone,   equals,   finalize,   getClass,   hashCode,   notify,   notifyAll,   toString,   wait,   wait,   wait
Method from org.apache.derby.iapi.services.monitor.Monitor Detail:
 public static Object bootServiceModule(boolean create,
    Object serviceModule,
    String factoryInterface,
    Properties properties) throws StandardException 
    Boot or find a unidentified module within a service. This call allows modules to start or create any modules they explicitly require to exist within their service. If no module matching the criteria is found (see this class's prologue for details) then an instance will be created (see prologue) and booted as follows.
    ((ModuleControl) instance).boot(create, (String) null, properties);
    

    The service is defined by the service that the module serviceModule lives in, typically this call is made from the boot method of a module and thus 'this' is passed in for serviceModule.
 public static Object bootServiceModule(boolean create,
    Object serviceModule,
    String factoryInterface,
    String identifier,
    Properties properties) throws StandardException 
    Boot or find a identified module within a service. This call allows modules to start or create any modules they explicitly require to exist within their service. If no module matching the criteria is found (see this class's prologue for details) then an instance will be created (see prologue) and booted as follows.
    ((ModuleControl) instance).boot(create, identifer, properties);
    

    The service is defined by the service that the module serviceModule lives in, typically this call is made from the boot method of a module and thus 'this' is passed in for serviceModule.
 public static InstanceGetter classFromIdentifier(int identifier) throws StandardException 
    Obtain the class object for a class that supports the given identifier. If no class has been registered for the identifier then a StandardException is thrown with no attached java.lang exception (nextException). If a problem loading or accessing the class is obtained then a StandardException is thrown with the real java.lang exception attached.
 public static  void clearMonitor() 
 public static Object createPersistentService(String factoryInterface,
    String serviceName,
    Properties properties) throws StandardException 
    Create a named service that implements the java interface (or class) fully qualified by factoryInterface. The Properties object specifies create time parameters to be used by the modules within the service. Any module created by this service may add or remove parameters within the properties object in their ModuleControl.boot() method. The properties set will be saved by the Monitor for later use when the monitor is started.

    Context
    A context manager will be created and installed at the start of this method and destroyed just before this method returns.

 public static StandardException exceptionStartingModule(Throwable t) 
    return a StandardException to indicate that an exception caused starting the module to fail.
 public static Object findService(String factoryInterface,
    String serviceName) 
    Find a service.
 public static Object findServiceModule(Object serviceModule,
    String factoryInterface) throws StandardException 
    Find an unidentified module within a service.
    The service is defined by the service that the module serviceModule lives in.
 public static Object findSystemModule(String factoryInterface) throws StandardException 
    Find a module in the system service.
 public static int getEngineType(Properties startParams) 
 public static Locale getLocaleFromString(String localeDescription) throws StandardException 
    Translate a localeDescription of the form ll[_CC[_variant]] to a Locale object.
 public static ModuleFactory getMonitor() 
    Get the monitor.
 public static ModuleFactory getMonitorLite() 
 public static Object getServiceModule(Object serviceModule,
    String factoryInterface) 
 public static String getServiceName(Object serviceModule) 
    Return the name of the service that the passed in module lives in.
 public static HeaderPrintWriter getStream() 
 public static Object getSystemModule(String factoryInterface) 
    Return a system module. If it cannot be found or the monitor is not running then null is returned.
 public static boolean isDesiredCreateType(Properties p,
    int type) 
    Return true if the properties set provided contains database creation attributes for a database of the correct type
 public static boolean isDesiredType(Properties startParams,
    int desiredProperty) 
 public static boolean isDesiredType(int engineType,
    int desiredType) 
    Is engineType a match for desiredType. A match exists if the bit intersect of the two values is no zero.
 public static boolean isFullUpgrade(Properties startParams,
    String oldVersionInfo) throws StandardException 
    Single point for checking if an upgrade is allowed.
 public static  void logMessage(String messageText) 
 public static  void logTextMessage(String messageID) 
 public static  void logTextMessage(String messageID,
    Object a1) 
 public static  void logTextMessage(String messageID,
    Object a1,
    Object a2) 
 public static  void logTextMessage(String messageID,
    Object a1,
    Object a2,
    Object a3) 
 public static  void logTextMessage(String messageID,
    Object a1,
    Object a2,
    Object a3,
    Object a4) 
 public static  void logThrowable(Throwable t) 
    Logs the stack trace of the specified throwable object.
 public static StandardException missingImplementation(String implementation) 
    return a StandardException to indicate a missing implementation.
 public static StandardException missingProductVersion(String productGenusName) 
    return a StandardException to indicate that a module failed to start because it could not obtain the version of a required product.
 public static Object newInstanceFromIdentifier(int identifier) throws StandardException 
    Obtain an new instance of a class that supports the given identifier. If no class has been registered for the identifier then a StandardException is thrown with no attached java.lang exception (getNestedException). If a problem loading or accessing the class or creating the object is obtained then a StandardException is thrown with the real java.lang exception attached.
 public static  void removePersistentService(String name) throws StandardException 
 public static boolean setMonitor(ModuleFactory theMonitor) 
    Initialise this class, must only be called by an implementation of the monitor (ModuleFactory).
 public static  void startMonitor(Properties bootProperties,
    PrintStream logging) 
    Start a Monitor based software system. This method will execute the following steps.
    1. Create an instance of a module (monitor) of the required implementation.
    2. Start the monitor which will in turn start any requested services
    3. Execute the run() method of startCode (if startCode was not null).
    4. Return.

    If MonitorBoot.start() is called more then once then subsequent calls have no effect.

 public static Object startNonPersistentService(String factoryInterface,
    String serviceName,
    Properties properties) throws StandardException 
    Start a non-persistent service.

    Context
    A context manager will be created and installed at the start of this method and destroyed just before this method returns.

 public static boolean startPersistentService(String serviceName,
    Properties properties) throws StandardException 
    Start a persistent service. The name of the service can include a service type, in the form 'type:serviceName'.
    Note that the return type only indicates if the service can be handled by the monitor. It does not indicate the service was started successfully. The cases are
    1. Service type not handled - false returned.
    2. Service type handled, service does not exist, true returned.
    3. Service type handled, service exists and booted OK, true returned.
    4. Service type handled, service exists and failed to boot, exception thrown.
    If true is returned then findService should be used to see if the service exists or not.

    The poperty set passed in is for boot options for the modules required to start the service. It does not support defining different or new modules implementations.

 public static Object startSystemModule(String factoryInterface) throws StandardException 
    Start or find a module in the system service. This call allows modules to explictly start services they require. If no module matching the criteria is found (see this class's prologue for details) then an instance will be created (see prologue) and booted as follows.
    ((ModuleControl) instance).boot(false, (String) null, (Properties) null);