All Known Implementing Classes:
URLStorageFactory, CPStorageFactory, DirStorageFactory4, VFMemoryStorageFactory, BaseStorageFactory, DirStorageFactory, JarStorageFactory, WritableStorageFactory
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: |
|---|
|
|
|
|
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. |
The init method will be called once, before any other method is called, and will not be called again. |
|
|
|
|
|
|
|