Save This Page
Home » db-derby-10.5.3.0 » org.apache.derby.io » [javadoc | source]
org.apache.derby.io
public interface: StorageFactory [javadoc | source]

All Known Implementing Classes:
    URLStorageFactory, CPStorageFactory, DirStorageFactory4, VFMemoryStorageFactory, BaseStorageFactory, DirStorageFactory, JarStorageFactory, WritableStorageFactory

This interface provides basic storage functions needed for read only databases. Most storage implementations will be read-write and implement the WritableStorageFactory extension of this interface.

The database engine uses this interface to access storage. The normal database engine implements this interface using disk files and the standard java.io classes.

The storage factory must implement writable temporary files, even if the database is read-only or if the storage factory is read-only (i.e. it does not implement the WritableStorageFactory extension of this interface). Temporary files are those created under the temporary file directory. See method getTempDir() .

The database engine can be turned into a RAM based engine by providing a RAM based implementation of this interface.

There is one instance of the StorageFactory per database if the log files are kept in the database directory. If the log files are kept on a separate device then a second StorageFactory is instantiated to hold the log files. The database or log device name is set when the init method is called. The init method is called once per instance, before any other StorageFactory method.

The class implementing this interface must have a public niladic constructor. The init method will be called before any other method to set the database directory name, to tell the factory to create the database directory if necessary, and to allow the implementation to perform any initializations it requires. The database name set in the init method forms a separate name space. Different StorageFactory instances, with different database directory names, must ensure that their files do not clash. So, for instance, storageFactory1.newStorageFile( "x") must be a separate file from storageFactory2.newStorageFile( "x").

The database engine will call this interface's methods from its own privilege blocks. This does not give a StorageFactory implementation carte blanche: a security manager can still forbid the implemeting class from executing a privileged action. However, the security manager will not look in the calling stack beyond the database engine.

Each StorageFactory instance may be concurrently used by multiple threads. Each StorageFactory implementation must be thread safe.

A StorageFactory implementation is plugged into the database engine via a sub-protocol. Sub-protocol xxx is tied to a StorageFactory implementation class via the derby.subSubProtocol.xxx system property. So, to use StorageFactory implementation class MyStorageFactory with database myDB you would set the system property "derby.subSubProtocol.mysf=MyStorageFactory" and use the URL "jdbc:derby:mysf:myDB" to connect to the database.

Field Summary
 int VERSION_NUMBER    The version number of this version of the StorageFactory interface and its subsidiary interfaces. 
Method from org.apache.derby.io.StorageFactory Summary:
createTemporaryFile,   getCanonicalName,   getSeparator,   getStorageFactoryVersion,   getTempDir,   init,   isFast,   isReadOnlyDatabase,   newStorageFile,   newStorageFile,   newStorageFile,   shutdown,   supportsRandomAccess
Method from org.apache.derby.io.StorageFactory Detail:
 public StorageFile createTemporaryFile(String prefix,
    String suffix) throws IOException
    Create and returns a temporary file in temporary file system of database
 public String getCanonicalName() throws IOException
    Get the canonical name of the database. This is a name that uniquely identifies it. It is system dependent. The normal, disk based implementation uses method java.io.File.getCanonicalPath on the directory holding the database to construct the canonical name.
 public char getSeparator()
    Get the pathname separator character used by the StorageFile implementation. This is the separator that must be used in directory and file name strings.
 public int getStorageFactoryVersion()
 public StorageFile getTempDir()
    Get the abstract name of the directory that holds temporary files.

    The StorageFactory implementation is not required to make temporary files persistent. That is, files created in the temp directory are not required to survive a shutdown of the database engine.

    However, files created in the temp directory must be writable, even if the database is otherwise read-only.

 public  void init(String home,
    String databaseName,
    String tempDirName,
    String uniqueName) throws IOException
    Classes implementing the StorageFactory interface must have a null constructor. The init method is called when the database is booted up to initialize the class. It should perform all actions necessary to start the basic storage, such as creating a temporary file directory. This method should not create the database directory.

    The init method will be called once, before any other method is called, and will not be called again.

 public boolean isFast()
    This method is used to determine whether the storage is fast (RAM based) or slow (disk based). It may be used by the database engine to determine the default size of the page cache.
 public boolean isReadOnlyDatabase()
    Determine whether the database is read only. The database engine supports read-only databases, even in file systems that are writable.
 public StorageFile newStorageFile(String path)
    Construct a StorageFile from a path name.
 public StorageFile newStorageFile(String directoryName,
    String fileName)
    Construct a non-temporary StorageFile from a directory and file name.
 public StorageFile newStorageFile(StorageFile directoryName,
    String fileName)
    Construct a StorageFile from a directory and file name. The StorageFile may denote a temporary file or a non-temporary database file, depending upon the directoryName parameter.
 public  void shutdown()
    The shutdown method is called during the normal shutdown of the database. However, the database engine cannot guarantee that shutdown will be called. If the JVM terminates abnormally then it will not be called.
 public boolean supportsRandomAccess()
    Determine whether the storage supports random access. If random access is not supported then it will only be accessed using InputStreams and OutputStreams (if the database is writable).