| 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
StorageFactory.getTempDir 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.
See Also: WritableStorageFactory
See Also: StorageFile
See Also: StorageRandomAccessFile
See Also: java.io.File
See Also: java.io.RandomAccessFile
See Also: java.io.InputStream
See Also: java.io.OutputStream |