*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 “janusgraph.properties” 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: https://github.com/JanusGraph/janusgraph/issues/2238

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

Regards,

Jun