To Introduce Transaction Context to Allow Per-Transaction Configuration In JanusGraph Storage Plugin #2238

Jun Li <jltz9...@...>

Hi All,

As I am working on the feature improvement on JanusGraph-FoundationDB storage plugin, I found the need to introduce per-transaction configuration via a Transaction Context object. I have submitted the new API feature needed at

As a summary, in JanusGraph-FoundationDB storage plugin, we like to have the following features to greatly improve functionality and performance:

*Allow the application to provide the hint that “the query is read-only” and thus we can use pre-fetching Global Read Version (GRV) to reduce query latency. In 3-datacenter deployment, we found that query latency can be reduced with 50 ms from this optimization.
*Allow the application to choose different transaction modes. The “serializable” mode is desired for “write-related queries”, but for “read-only queries”, the application may choose “read_committed_with_write” mode to circumvent the 5-second transaction time limit imposed by FoundationDB today.

To achieve the above improvement, we will need to have a Transaction Context object to be associated with the JanusGraph Transaction, so that the above query optimization configuration parameters can be specified in the Transaction Context and is associated with each individual transaction (query). Note that read-only queries and write-related queries can concurrently be processed in the same Graphdb.

Today, all of the JanusGraph configuration parameters are set at the JanusGraph process start-time from the property file “” or from the “store features” set by the Store Manager. Both mechanisms can not support per-transaction customization.

The proposed change is on JanusGraphTransaction interface to have two additional methods:

//defined in org.janusgraph.core 

interface Transaction { 

 void setContext (TransactionContext context); 

TransactionContext getContext(); 


More detail can be found at:

What do you think about this suggested API feature  to allow big performance improvement over the distributed transaction backend store?