Home >> All >> org >> apache >> derby >> impl >> store >> [ raw Javadoc ]

•	org.apache.derby.impl.store.raw.data.* (69)	•	org.apache.derby.impl.store.raw.log.* (15)
•	org.apache.derby.impl.store.raw.xact.* (23)

• org.apache.derby.impl.store.raw: Javadoc index of package org.apache.derby.impl.store.raw.


Package Samples:

• org.apache.derby.impl.store.raw.data
• org.apache.derby.impl.store.raw.log
• org.apache.derby.impl.store.raw.xact

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 ...
• 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 ...
• 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 ...
• 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 ...
• 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 ...
• 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 ...
• 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
• PageBasicOperation: A PageBasicOperation changed the content of a page, this is the root class of all page oriented operation. Each PageBasicOperation record change(s) that apply to one and only one page . The pageID that is changed must be recorded in the log operation - in other words, redo must be physical (or more correctly, in Gray's term, physiological, since changes are logical within a page). Undo can be logical, but the undo logic must be hidden in generateUndo. By the time a compensation operation is logged as a LogOperation, the page that needs roll back must be determined.
• BasePage: This class implements all the the generic locking behaviour for a Page. It leaves method used to log and store the records up to sub-classes. It is intended that the object can represent multiple pages from different containers during its lifetime. A page contains a set of records, which can be accessed by "slot", which defines the order of the records on the page, or by "id" which defines the identity of the records on the page. Clients access records by both slot and id, depending on their needs. BasePage implements Observer to watch the ContainerHandle which notifies its Observers when it is ...
• RowLocking2: A locking policy that implements row level locking with isolation degree 2. 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. All "read" container and row locks will be placed on a group list, key'd by the ContainerId of the lock. Locks on this list will either be released explicitly by the caller, or will be released as a group when the unlockContainer() call is made. Note that write operations extend from the RowLocking3 implementations.
• PhysicalPageOperation: An abstract class that is used for physical log operation. A physical log operation is one where the undo of the operation must be applied to the same page as the original operation, and the undo operation must store the byte image of the row(s) changed to its before image. (If a logical page operation happened to the page or if another transaction altered other rows on the page, the undo of this operation will only restore the before image of the row(s) affected).
• TransactionTableEntry: Transaction table entry is used to store all relavent information of a transaction into the transaction table for the use of checkpoint, recovery, Transaction management during Quiesce state, and for dumping transaction table. Only works with the following classes: TransactionTable, XactFactory, Xact During run time, whenever any transaction is started, it is put into the transaction table. Whenever any transaction is closed, it is removed from the transaction table.
• BaseContainer: BaseContainer is an abstract class that provides the locking bahaviour for an object representing an active container, that is the actual storage container, not the ContainerHandle interface. This class is designed so that it can change the container it represents to avoid creating a new object for every container. This object implements lockable to provide an object to lock while a page is being allocated. MT - Mutable - mutable identity :
• XactId: Use this class for a short hand representation of the transaction. This value is only guarentee to be unique within one continuous operation of the raw store, in other words, every reboot may reuse the same value. Whereas GlobalXactId is unique for all times across all raw store, a XactId is only unique within a particular rawstore and may be reused. XactId keeps track of the outstanding transactionId and is responsible for dispensing new transactionIds
• StreamFileContainer: The format of this stream file is: (RH) (FH) (field data) (FH) (field data) ........ (FH) (field data) Record header is stored once at the beginning of the file for all the rows stored in this file. Record Header indicates how many fields are in each row. Then we just stored all the column from each row. Field header stored on this file is fixed size with fieldDataLength size set to LARGE_SLOT_SIZE (4) bytes. NOTE: No locks are used in this container. All transaction are not logged.
• RememberBytesInputStream: A FilterInputStream that remembers read or skipped bytes. In record mode this stream remembers all the bytes a caller reads or skips. After reading some bytes this returns a 'replay' stream to re-read them. A caller may call getReplaySteam to get a stream to re-read the the remembered bytes. Any number of calls to getReplayStream are supported. The clear function causes this stream to forget the remembered bytes and re-enter record mode.
• Xact: A transaction has five states CLOSED - cannot be used IDLE - no reads have been performed by the transaction. ACTIVE - at least one read has been attempted by the transaction UPDATE - at least one update has been attempted by the transaction PREPARED - the transaction is ready to commit (FUTURE). Transaction identifiers are re-used for transactions that do not enter the UPDATE state during their lifetime.
• BaseContainerHandle: A handle to an open container, implememts RawContainerHandle. This class is an Observer to observe RawTransactions and is also a Observable to handle the list of pages accessed thorough this handle. This class implements Lockable (defined to be ContainerHandle) and is the object used to logically lock the container. MT - Mutable - Immutable identity - Thread Aware
• Scan: Scan the the log which is implemented by a series of log files.n This log scan knows how to move across log file if it is positioned at the boundary of a log file and needs to getNextRecord. 4 bytes - length of user data, i.e. N 8 bytes - long representing log instant N bytes of supplied data 4 bytes - length of user data, i.e. N
• LogCounter: A very simple log instant implementation. Within the stored log record a log counter is represented as a long, hence the getValueAsLong() method. Outside the LogFactory the instant is passed around as a LogCounter (through its LogInstant interface). The way the long is encoded is such that correctly tells if one log instant is lessThan, equals or greater than another.

Home | Contact Us | Privacy Policy | Terms of Service