|
From: Bryan T. <tho...@us...> - 2007-04-10 18:33:38
|
Update of /cvsroot/cweb/bigdata/src/java/com/bigdata/journal In directory sc8-pr-cvs4.sourceforge.net:/tmp/cvs-serv24584/src/java/com/bigdata/journal Modified Files: ResourceManager.java AbstractJournal.java Log Message: Fixed a bug in UUID assignment to index segments. Added some logic for fast data output for btree nodes and leaves. Index: ResourceManager.java =================================================================== RCS file: /cvsroot/cweb/bigdata/src/java/com/bigdata/journal/ResourceManager.java,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** ResourceManager.java 29 Mar 2007 17:01:33 -0000 1.2 --- ResourceManager.java 10 Apr 2007 18:33:31 -0000 1.3 *************** *** 53,56 **** --- 53,57 ---- import org.apache.log4j.Logger; + import com.bigdata.objndx.AbstractBTree; import com.bigdata.objndx.IndexSegment; import com.bigdata.objndx.IndexSegmentBuilder; *************** *** 179,182 **** --- 180,185 ---- * finalized (unisolated vs isolated vs index segment can be * identified based on their interfaces). + * + * @todo add reporting for {@link AbstractBTree#reopen()}. */ static public void closeUnisolatedBTree(String name) { Index: AbstractJournal.java =================================================================== RCS file: /cvsroot/cweb/bigdata/src/java/com/bigdata/journal/AbstractJournal.java,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -d -r1.10 -r1.11 *** AbstractJournal.java 4 Apr 2007 16:52:16 -0000 1.10 --- AbstractJournal.java 10 Apr 2007 18:33:31 -0000 1.11 *************** *** 158,167 **** * to secondary journals on failover hosts. </li> * <li> Scale-up database (automatic re-partitioning of indices and processing ! * of deletion markers).</li> ! * <li> AIO for the Direct and Disk modes.</li> * <li> GOM integration, including: support for primary key (clustered) indices; * using queues from GOM to journal/database segment server supporting both * embedded and remote scenarios; and using state-based conflict resolution to ! * obtain high concurrency for generic objects, link set metadata, and indices.</li> * <li> Scale-out database, including: * <ul> --- 158,170 ---- * to secondary journals on failover hosts. </li> * <li> Scale-up database (automatic re-partitioning of indices and processing ! * of deletion markers). Note that the split point must be choosen with some ! * awareness of the application keys in order to provide an atomic row update ! * guarentee when using keys formed as { primaryKey, columnName, timestamp }.</li> ! * <li> AIO for the Direct and Disk modes (low priority since not IO bound).</li> * <li> GOM integration, including: support for primary key (clustered) indices; * using queues from GOM to journal/database segment server supporting both * embedded and remote scenarios; and using state-based conflict resolution to ! * obtain high concurrency for generic objects, link set metadata, indices, and ! * distributed split cache and hot cache support.</li> * <li> Scale-out database, including: * <ul> *************** *** 177,180 **** --- 180,189 ---- * </ol> * + * @todo Move Addr methods onto IRawStore and store the bitsplit point in the + * root block. This will let us provision the journal to have more + * distinct offsets at which records can be written (e.g., 35 bits for + * that vs 32) by accepting a maximum record length with fewer bytes (29 + * vs 32). The bitsplit point can be choosen differently for each store. + * * @todo Define distributed transaction protocol. Pay attention to 2-phase or * 3-phase commits when necessary, but take advantage of locality when *************** *** 190,198 **** * failover. * ! * @todo I need to revisit the assumptions for very large objects in the face of ! * the recent / planned redesign. I expect that using an index with a key ! * formed as [URI][chuck#] would work just fine. Chunks would then be ! * limited to 32k or so. Writes on such indices should probably be ! * directed to a journal using a disk-only mode. * * @todo Checksums and/or record compression are currently handled on a per-{@link BTree} --- 199,206 ---- * failover. * ! * @todo I need to revisit the assumptions for very large objects. I expect that ! * using an index with a key formed as [URI][chuck#] would work just fine. ! * Chunks would then be limited to 32k or so. Writes on such indices ! * should probably be directed to a journal using a disk-only mode. * * @todo Checksums and/or record compression are currently handled on a per-{@link BTree} |