All Packages from org.apache.derby.impl.store.access.* to org.apache.derby.impl.store.raw.*

Home >> All >> org >> apache >> derby >> impl >> store

•

org.apache.derby.impl.store.access.* (81)

•

org.apache.derby.impl.store.raw.* (108)

Package Samples:

• org.apache.derby.impl.store.access.btree.index
• org.apache.derby.impl.store.access.btree
• org.apache.derby.impl.store.access.conglomerate
• org.apache.derby.impl.store.access.heap
• org.apache.derby.impl.store.access.sort
• org.apache.derby.impl.store.access
• org.apache.derby.impl.store.raw.data
• org.apache.derby.impl.store.raw.log
• org.apache.derby.impl.store.raw.xact
• org.apache.derby.impl.store.raw

Classes:

• ReclaimSpaceHelper: This class helps a BaseDataFactory reclaims unused space. Space needs to be reclaimed in the following cases: Row with long columns or overflow row pieces is deleted Insertion of a row that has long columns or overflows to other row pieces is rolled back Row is updated and the head row or some row pieces shrunk Row is updated and some long columns are orphaned because they are updated Row is updated and some long columns are created but the update rolled back Row is updated and some new row pieces are created but the update rolled back We can implement a lot of optimization if we know that btree ...
• StoredFieldHeader: A class to provide static methods to manipulate fields in the field header. A class StoredPage uses to read/write field status and field data length. No attributes exist in this class, this class provides a set of static methods for writing field status and field data length, and for reading field status and field data length. Stored Field Header Format The field header is broken into two sections. Only the Status byte is required to be there. Field header format: +--------+-------------------+ | status | | +--------+-------------------+ Overflow page and overflow id are stored as field data. If ...
• AllocPage: An allocation page of the file container. This class extends a normal Stored page, with the exception that a hunk of space may be 'borrowed' by the file container to store the file header. The borrowed space is not visible to the alloc page even though it is present in the page data array. It is accessed directly by the FileContainer. Any change made to the borrowed space is not managed or seen by the allocation page. Page Format An allocation page extends a stored page, the on disk format is different from a stored page in that N bytes are 'borrowed' by the container and the page header of an ...
• GenericScanController: Generic class implementing shared ScanController methods. Logically a scancontroller is used to scan a set of rows that meet some specified qualification. Rows that meet the qualification may be operated upon by the scan to fetch, delete, or replace. The ScanController also supports the notion or "repositioning" the scan, which simply resets the beginning of the scan to a new place, and allows the user to continue from there. This class attempts to abstract out some of the parts of the scan such that maybe multiple access methods can share code, even if they perform parts of the scan wildly differently. ...
• LogAccessFile: Wraps a RandomAccessFile file to provide buffering on log writes. Only supports the write calls required for the log! MT - unsafe. Caller of this class must provide synchronization. The one exception is with the log file access, LogAccessFile will touch the log only inside synchronized block protected by the semaphore, which is defined by the creator of this object. Write to the log buffers are allowed when there are free buffers even when dirty buffers are being written(flushed) to the disk by a different thread. Only one flush writes to log file at a time, other wait for it to finish. Except ...
• BTreeLockingPolicy: The generic.BTree directory wants to know as little about locking as possible, in order to make the code usuable by multiple implementations. But the generic code will make calls to abstract lock calls implemented by concrete btree implementations. Concrete implementations like B2I understand locking, and needs informatation specific to the implementation to make the lock calls. This class is created and owned by the concrete application, but is passed into and returned from the generic code when lock calls are made. Concrete implementations which do not need lock calls can just pass a null pointer ...
• LogToFile: This is an implementation of the log using a non-circular file system file. No support for incremental log backup or media recovery. Only crash recovery is supported. The 'log' is a stream of log records. The 'log' is implemented as a series of numbered log files. These numbered log files are logically continuous so a transaction can have log records that span multiple log files. A single log record cannot span more then one log file. The log file number is monotonically increasing. The log belongs to a log factory of a RawStore. In the current implementation, each RawStore only has one log factory, ...
• TransactionTable: The transaction table is used by the transaction factory to keep track of all transactions that are in the system. The transction table serves the following purposes: checkpoint - when a checkpoint log record is written out, it writes out also all transactions that have updated the database. RESOLVE: this is actually not used right now - rather, the transaction table is reconstructed during the redo phase by traversing from the undo LWM. It is a goal to use this transaction table (and traversing from the redoLWM) instead of rebuilding it to speed up recovery. Quiesce State - when a system enters ...
• ContainerOperation: Log operation to create, drop or remove a container. Both the doMe or the undoMe of a create actually caused the container header to be modified and flushed before the log record is flushed. This is necessary for 2 reasons, one is that of ensuring enough disk space, and the other is because unlike any other operation, the log record create container is in the log stream before the container is in the container cache. What this mean is that if a checkpoint started after the container operation but before the container is kept or is dirtied in the container cache, then checkpoint will not know to ...
• B2I: Implements an instance of a B-Tree secondary index conglomerate. A B2I object has two roles. The B2I object is stored on disk, and holds the store specific information needed to access/describe the conglomerate. This includes information such as the format ids of the columns, the conglomerate id of the base table, the location of row location column. Access to all the interfaces start by making a call off the Conglomerate interface. So for instance to get a scan on the conglomerate method openScan 55 should be called.
• HeapCostController: The StoreCostController interface provides methods that an access client (most likely the system optimizer) can use to get store's estimated cost of various operations on the conglomerate the StoreCostController was opened for. It is likely that the implementation of StoreCostController will open the conglomerate and will leave the conglomerate open until the StoreCostController is closed. This represents a significant amount of work, so the caller if possible should attempt to open the StoreCostController once per unit of work and rather than close and reopen the controller. For instance if the ...
• XactXAResourceManager: The XactXAResourceManager implements the Access XAResource interface, which provides offline control over two phase commit transactions. It is expected to be used by TM's (transaction manager's), to recover if systems fail while transactions are still in-doubt (prepared). This interface allows access to commit,prepare,abort global transactions as part of a two phase commit protocol. These interfaces have been chosen to be exact implementations required to implement the XAResource interfaces as part of the JTA standard extension. It is expected that the following interfaces are only used during ...
• ControlRow: Base class for leaf and branch control rows. Concurrency Notes All access through control rows is serialized by an exclusive latch on the page the control row is for. The page is latched when the control row is "gotten" (ControlRow#Get), and unlatched when the control row is released (ControlRow#release). To Do List [NOTE1] The code is arranged to fault in fields from the row as necessary. many of the fields of a control row are rarely used (left sibling, parent). The accessors fault in the underlying column only when requested by allocating the appropriate object and calling fetchFromSlot and ...
• BTreeCostController: The StoreCostController interface provides methods that an access client (most likely the system optimizer) can use to get store's estimated cost of various operations on the conglomerate the StoreCostController was opened for. It is likely that the implementation of StoreCostController will open the conglomerate and will leave the conglomerate open until the StoreCostController is closed. This represents a significant amount of work, so the caller if possible should attempt to open the StoreCostController once per unit of work and rather than close and reopen the controller. For instance if the ...
• PropertyConglomerate: Stores properties in a congolmerate with complete transactional support. The PropertyConglomerate contains one row with 2 columns per property. Column 0 is the UTF key, and column 1 is the data. The property conglomerate manages the storage of database properties and thier defaults. Each property is stored as a row in the PropertyConglomerate Column 0 is the UTF key, Column 1 is the data. All the property defaults are stored in a single row of the Property Conglomerate: Column 0 is the UTF key "derby.defaultPropertyName". Column 1 is a FormatableProperties object with one row per default property. ...
• HeapPostCommit: The HeapPostCommit class implements the Serviceable protocol. In it's role as a Serviceable object, it stores the state necessary to find a page in a heap that may have committed delete's to reclaim. It looks up the page described, and reclaims space in the conglomerate. It first trys to clean up any deleted commits on the page. It will then deallocate the page if no rows remain on the page. All work is done while holding the latch on the page, and locks are never "waited" on while holding this latch. This implementation uses record level locking to reclaim the space. For the protocols to work ...
• BTree: A b-tree object corresponds to an instance of a b-tree conglomerate. It contains the static information about a conglomerate which is built at create conglomerate time. This generic implementation is expected to be extended by the concreate implementations. The fields are set when the conglomerate is created and never changed thereafter. When alter table is supported then it will change under the control of a table level lock. They have package scope because they're read by the scans and controllers. A table of all conglomerates in the system is maintained by the accessmanager. A cache of conglomerates ...
• RowLocking1: A locking policy that implements row level locking with isolation degree 1. This is an implementation of Gray's degree 1 isolation, read uncommitted, or often referred to as dirty reads. Basically read operations are done with no locking. This locking policy is only to be used for read operations. The approach is to place all "write" container and row locks on the transaction group lock list. Locks on this group will last until end of transaction. This implementation will still get table level intent locks. This is to prevent hard cases where the container otherwise could be deleted while read ...
• AllocationCache: An auxiliary object to cache the allocation information for a file container. Only a FileContainer should use this object The allocation cache contains an array of AllocExtents and 3 arrays of longs: ExtentPageNums[i] is the page number of the i'th extent lowRange[i] is the smallest page number managed by extent i hiRange[i] is the largest page number managed by extent i Note thate extentPageNums and lowRange does not change once the extent has been created, but hiRange will change for the last extent as more pages are allocated. Extents can be individually invalidated or the entire cache (all ...
• B2IForwardScan: The btree secondary index implementation of ScanManager which provides reading and deleting of entries in the btree secondary index. This supports setting up and iterating through a set of rows while providing a start key, stop key, and a set of AND and OR qualifiers to skip unwanted rows. Currently derby only supports forward scans (but individual columns can have descending order). This interface is also used to delete rows from the conglomerate. Note that update is not supported, it must be implemented as a delete, followed by an insert. Note most work of this class is inherited from the generic ...
• BaseDataFileFactory: Provides the abstract class with most of the implementation of DataFactory and ModuleControl shared by all the different filesystem implementations. RESOLVE (mikem - 2/19/98) - Currently only getContainerClass() is abstract, there are probably more routines which should be abstract. Also the other implementations should probably inherit from the abstract class, rather than from the DataFileFactory class. Also there probably should be a generic directory and the rest of the filesystem implementations parallel to it. I wanted to limit the changes going into the branch and then fix inheritance stuff ...
• CacheableConglomerate: The CacheableConglomerate implements a single item in the cache used by the Conglomerate directory to cache Conglomerates. It is simply a wrapper object for the conglomid and Conglomerate object that is read from the Conglomerate Conglomerate. It is a wrapper rather than extending the conglomerate implementations because we want to cache all conglomerate implementatations: (ie. Heap, B2I, ...). References to the Conglomerate objects cached by this wrapper will be handed out to callers. When this this object goes out of cache callers may still have references to the Conglomerate objects, which we ...
• BranchRow: Implements row which is stored in the branch pages of a btree. A non-suffix compressed branch row contains all of the columns of the leaf rows of a btree and contains an additional field at the end. The extra field of a branch row in a branch page at level N, is the child page field pointing the page at level N-1 which has keys which follow or equal the branch row entry. There are 3 ways to use this class to produce a branch row: createEmptyTemplate() creates a empty row template createBranchRowFromOldBranchRow() creates a new row with reference to an old branch row. createBranchRowFromOldLeafRow() ...
• StoredRecordHeader: A class StoredPage uses to cache record headers by passing instances to BasePage, and to write stored versions of record headers. Format 1 byte - status compressed int - record identifier compressed long - overflow page } only if hasOverflow() is true compressed int - overflow id } " " " compressed int - first field } only if hasFirstField set - otherwise 0 compressed int - number of fields in this portion - only if hasOverflow() is false OR hasFirstField is true - otherwise 0
• B2IFactory: The "B2I" (acronym for b-tree secondary index) factory manages b-tree conglomerates implemented on the raw store which are used as secondary indexes. 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 ...

Home | Contact Us | Privacy Policy | Terms of Service