ModuleControl
, ModuleSupportable
, ConglomerateFactory
, MethodFactory
public class B2IFactory extends java.lang.Object implements ConglomerateFactory, ModuleControl
Most of this code is generic to all conglomerates. This class might be more easily maintained as an abstract class in Raw/Conglomerate/Generic. The concrete ConglomerateFactories would simply have to supply the IMPLEMENTATIONID, FORMATUUIDSTRING, and implement createConglomerate and defaultProperties. Conglomerates which support more than one format would have to override supportsFormat, and conglomerates which support more than one implementation would have to override supportsImplementation.
Modifier and Type | Field | Description |
---|---|---|
private UUID |
formatUUID |
|
private static java.lang.String |
FORMATUUIDSTRING |
|
private static java.lang.String |
IMPLEMENTATIONID |
BTREE_FACTORY_ID, HEAP_FACTORY_ID
MODULE
Constructor | Description |
---|---|
B2IFactory() |
Modifier and Type | Method | Description |
---|---|---|
void |
boot(boolean create,
java.util.Properties startParams) |
Boot this module with the given properties.
|
boolean |
canSupport(java.util.Properties startParams) |
See if this implementation can support any attributes that are listed in properties.
|
Conglomerate |
createConglomerate(TransactionManager xact_mgr,
int segment,
long input_containerid,
DataValueDescriptor[] template,
ColumnOrdering[] columnOrder,
int[] collationIds,
java.util.Properties properties,
int temporaryFlag) |
Create the conglomerate and return a conglomerate object for it.
|
java.util.Properties |
defaultProperties() |
Return the default properties for this kind of conglomerate.
|
int |
getConglomerateFactoryId() |
Return the conglomerate factory id.
|
private static ModuleFactory |
getMonitor() |
Privileged Monitor lookup.
|
void |
insertUndoNotify(AccessFactory access_factory,
Transaction xact,
PageKey page_key) |
Interface to be called when an undo of an insert is processed.
|
UUID |
primaryFormat() |
Return the primary format that this access method supports.
|
java.lang.String |
primaryImplementationType() |
Return the primary implementation type for this access method.
|
Conglomerate |
readConglomerate(TransactionManager xact_manager,
ContainerKey container_key) |
Return Conglomerate object for conglomerate with conglomid.
|
void |
stop() |
Stop the module.
|
boolean |
supportsFormat(UUID formatid) |
Return whether this access method supports the format supplied in
the argument.
|
boolean |
supportsImplementation(java.lang.String implementationId) |
Return whether this access method implements the implementation
type given in the argument string.
|
private static final java.lang.String IMPLEMENTATIONID
private static final java.lang.String FORMATUUIDSTRING
private UUID formatUUID
public java.util.Properties defaultProperties()
defaultProperties
in interface MethodFactory
MethodFactory.defaultProperties()
public boolean supportsImplementation(java.lang.String implementationId)
supportsImplementation
in interface MethodFactory
MethodFactory.supportsImplementation(java.lang.String)
public java.lang.String primaryImplementationType()
primaryImplementationType
in interface MethodFactory
MethodFactory.primaryImplementationType()
public boolean supportsFormat(UUID formatid)
supportsFormat
in interface MethodFactory
MethodFactory.supportsFormat(org.apache.derby.catalog.UUID)
public UUID primaryFormat()
primaryFormat
in interface MethodFactory
MethodFactory.primaryFormat()
public int getConglomerateFactoryId()
Return a number in the range of 0-15 which identifies this factory. Code which names conglomerates depends on this range currently, but could be easily changed to handle larger ranges. One hex digit seemed reasonable for the number of conglomerate types being currently considered (heap, btree, gist, gist btree, gist rtree, hash, others? ).
getConglomerateFactoryId
in interface ConglomerateFactory
ConglomerateFactory.getConglomerateFactoryId()
public Conglomerate createConglomerate(TransactionManager xact_mgr, int segment, long input_containerid, DataValueDescriptor[] template, ColumnOrdering[] columnOrder, int[] collationIds, java.util.Properties properties, int temporaryFlag) throws StandardException
createConglomerate
in interface ConglomerateFactory
xact_mgr
- transaction to perform the create in.segment
- segment to create the conglomerate in.input_containerid
- containerid to assign the container, or
ContainerHandle.DEFAULT_ASSIGN_ID if you want
raw store to assign an id.template
- Template of row in the conglomerate.columnOrder
- columns sort order for Index creationcollationIds
- collation ids of columns in the conglomerate.properties
- Properties associated with the conglomerate.StandardException
- Standard exception policy.ConglomerateFactory.createConglomerate(org.apache.derby.iapi.store.access.conglomerate.TransactionManager, int, long, org.apache.derby.iapi.types.DataValueDescriptor[], org.apache.derby.iapi.store.access.ColumnOrdering[], int[], java.util.Properties, int)
public Conglomerate readConglomerate(TransactionManager xact_manager, ContainerKey container_key) throws StandardException
Return the Conglomerate Object. This is implementation specific. Examples of what will be done is using the id to find the file where the conglomerate is located, and then executing implementation specific code to instantiate an object from reading a "special" row from a known location in the file. In the btree case the btree conglomerate is stored as a column in the control row on the root page.
This operation is costly so it is likely an implementation using this will cache the conglomerate row in memory so that subsequent accesses need not perform this operation.
The btree object returned by this routine may be installed in a cache so the object must not change.
readConglomerate
in interface ConglomerateFactory
xact_manager
- transaction to perform the create in.container_key
- The unique id of the existing conglomerate.StandardException
- Standard exception policy.public void insertUndoNotify(AccessFactory access_factory, Transaction xact, PageKey page_key) throws StandardException
Implementer of this class provides interface to be called by the raw store when an undo of an insert is processed. Initial implementation will be by Access layer to queue space reclaiming events if necessary when a rows is logically "deleted" as part of undo of the original insert. This undo can happen a lot for many applications if they generate expected and handled duplicate key errors.
Caller may decide to call or not based on deleted row count of the page, or if overflow rows/columns are present.
insertUndoNotify
in interface ConglomerateFactory
access_factory
- current access_factory of the aborted insert.xact
- transaction that is being backed out.page_key
- page key of the aborted insert.StandardException
- Standard exception policy.public boolean canSupport(java.util.Properties startParams)
ModuleSupportable
The module can check for attributes in the properties to
see if it can fulfill the required behaviour. E.g. the raw
store may define an attribute called RawStore.Recoverable.
If a temporary raw store is required the property RawStore.recoverable=false
would be added to the properties before calling bootServiceModule. If a
raw store cannot support this attribute its canSupport method would
return null. Also see the Monitor class's prologue to see how the
identifier is used in looking up properties.
Actually a better way maybe to have properties of the form
RawStore.Attributes.mandatory=recoverable,smallfootprint and
RawStore.Attributes.requested=oltp,fast
canSupport
in interface ModuleSupportable
public void boot(boolean create, java.util.Properties startParams) throws StandardException
ModuleControl
An implementation's boot method can throw StandardException. If it is thrown the module is not registered by the monitor and therefore cannot be found through a findModule(). In this case the module's stop() method is not called, thus throwing this exception must free up any resources.
When create is true the contents of the properties object
will be written to the service.properties of the persistent
service. Thus any code that requires an entry in service.properties
must explicitly place the value in this properties set
using the put method.
Typically the properties object contains one or more default
properties sets, which are not written out to service.properties.
These default sets are how callers modify the create process. In a
JDBC connection database create the first set of defaults is a properties
object that contains the attributes that were set on the jdbc:derby: URL.
This attributes properties set has the second default properties set as
its default. This set (which could be null) contains the properties
that the user set on their DriverManager.getConnection() call, and are thus
not owned by Derby code, and thus must not be modified by Derby
code.
When create is false the properties object contains all the properties set in the service.properties file plus a limited number of attributes from the JDBC URL attributes or connection properties set. This avoids properties set by the user compromising the boot process. An example of a property passed in from the JDBC world is the bootPassword for encrypted databases.
Code should not hold onto the passed in properties reference after boot time as its contents may change underneath it. At least after the complete boot is completed, the links to all the default sets will be removed.
boot
in interface ModuleControl
StandardException
- Module cannot be started.Monitor
,
ModuleFactory
public void stop()
ModuleControl
stop
in interface ModuleControl
Monitor
,
ModuleFactory
private static ModuleFactory getMonitor()
Apache Derby V10.14 Internals - Copyright © 2004,2018 The Apache Software Foundation. All Rights Reserved.