Released on July 19, 2013: Initial version supporting Blueprints version 2.3.0. No major bugs reported in the 3 month beta period.
Released on Aug 21, 2013
#6, #8, #9: Configurable isolation levels: read-committed and repeatable-read
#7: Canonicalize strings to save memory
#5: removeVertex() doesn't throw error when called twice
#2: Commit/rollback() on ThreadedTransactionalGraph failed with the new Blueprints API 2.3.0 API
#3: ConcurrentModificationException when using the results of an index
Released on Oct 8, 2013:
- (Done) Port to for Blueprints 2.4.0.
- (Done) Sync up JUNIT tests with latest version
#10: You can now use com.lambdazen.bitsy.wrapper.BitsyAutoReloadingGraph to wrap a BitsyGraph object so that it automatically reloads vertices and edges by their ID if they are accessed outside the scope of the transaction in which they are created. Note that according to the Blueprints spec, you need to recreate the vertex and edge objects in each transaction from the identifiers. This workaround is for existing programs that rely on the auto-reloading of vertices available in other graph databases.
#11: Both BitsyGraph and BitsyAutoReloadingGraph expose a method called isTransactionActive() to indicate whether/not a transaction is in progress. This is related to a Blueprints feature request at https://github.com/tinkerpop/blueprints/issues/435
Released on Oct 10, 2013:
This presentation covers the improvements in version 1.5. The release number will change as of version 1.5.0 to a three-digit scheme where the third digit captures releases with minor features, bug-fixes and ports to new versions of Blueprints.
Please use this version for research, evaluation and development. Version 1.2 should be used in production till the end of 2013.
- Memory efficient data structures
- (Mostly) lock-free read algorithms
- Port to Blueprints 2.4.0
Released on Oct 27, 2013:
- Improved performance when operating on large degree vertices (issue
- toString() methods on vertex and edge now follow Blueprints convention (issue
Planned for Q1 2014: Version 2.0 will provide tools to build a stateful cluster of Bitsy applications that operate on several graphs and expose remote operations to a stateless cluster of client applications.
Version 2.0 will still follow the original design principles, viz. No Seek, No Socket, No SQL, for the common-case. Sockets will be used in cache-able lookups to Zookeeper from the client applications to locate the database application that holds a specific graph. Sockets will also be used to perform transfers of graphs from one server in the stateful cluster to another.
There are no plans to support graphs that span multiple machines in the cluster. ACID is hard to achieve in this setting because automatic graph partioning is [NP-hard](NP-hard. Without partitioning, we need two-phase commits on multiple servers which will slowdown Bitsy.
- Support for multiple graphs in a Bitsy database (a form of sharding)
- Integration with Zookeeper to locate the server that owns a graph
- Methods to move a graph-shard from one database to another
- Methods to perform a manual hot failover of an entire server
- Improve startup performance
- Move to Java 8, which includes a better ConcurrentHashMap (smaller, faster)