See: Description
Class | Description |
---|---|
B2I |
Implements an instance of a B-Tree secondary index conglomerate.
|
B2I_10_3 |
Class used to instantiate 10.3 version of the B2I object.
|
B2I_v10_2 |
Class used to instantiate 10.2 version of the B2I object.
|
B2IController |
Controller used to insert rows into a secondary index.
|
B2ICostController |
Controller used to provide cost estimates to optimizer about secondary index
data access.
|
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.
|
B2IForwardScan |
The btree secondary index implementation of ScanManager which provides reading
and deleting of entries in the btree secondary index.
|
B2IMaxScan |
Scan used to find maximum value in the secondary index.
|
B2INoLocking |
Secondary index locking policy that does no locking.
|
B2IRowLocking1 |
The btree locking policy which implements read uncommitted isolation level.
|
B2IRowLocking2 |
The btree locking policy which implements read committed isolation level.
|
B2IRowLocking3 |
Implements the jdbc serializable isolation level using row locks.
|
B2IRowLockingRR | |
B2IStaticCompiledInfo |
This class implements the static compiled information relevant to a btree
secondary index.
|
B2ITableLocking3 | |
B2IUndo |
The B2IUndo interface packages up the routines which the rawstore needs
to call to perform logical undo of a record in a B2i.
|
D_B2IController |
Debugging class used to print debug information about a B2I.
|
Implements classes used by the language layer to implement
SQL secondary indexes. The classes here extend and use the classes in
org.apache.derby.impl.store.access.btree
to implement
a locked btree index.
The key to understanding the class layout is to understand the public
store interfaces in
org.apache.derby.iapi.store.access.conglomerate
, which contains
the shared interfaces that must be implemented by all access methods.
Currently Derby implements heap and btree index access methods. Users of
access methods use the same interface no matter what the underlying
type or particular implementation of the access method. Therefore, Derby
can support multiple types of btree index implementations, which if done
right should require no changes to actual users of the access methods.
In reality the interfaces would have to change in some ways to support a radically different kind of access method, such as GiST. But the implementor should enhance the interfaces in the conglomerate package so that these can then be supported by all existing access methods.
Isolation level implementation in the B-Tree index is done with data
only locking, i.e., locks on secondary index rows are actually locks on the
data rows that they point to. The specifics of particular isolation levels
are hidden in various implementations of the BTreeLockingPolicy
class.
The classes which do scans, deletes, and inserts do not have isolation
specific code, instead they make lock calls using BTreeLockingPolicy
interfaces, and then depending on the isolation level one of the implmentations
does the actual locking.
Apache Derby V10.13 Internals - Copyright © 2004,2016 The Apache Software Foundation. All Rights Reserved.