JanusGraph之Transactions

1. Transaction Handling（事务处理）

JanusGraph中的每个图表操作都发生在事务的上下文中。根据TinkerPop的事务规范，每个线程在图上用第一个操作建立图数据库对应事务。

        graph = JanusGraphFactory.open("berkeleyje:/tmp/janusgraph")        juno = graph.addVertex() //Automatically opens a new transaction        juno.property("name", "juno")        graph.tx().commit() //Commits transaction

1. Transactional Scope（事务作用域）

   所有图形元素（顶点，边和类型）都与它们被检索或创建的事务范围相关联。在TinkerPop默认的事务语义下，事务是通过图上的第一个操作自动创建的，并使用commit()或者 rollback()。当事务关闭后，JanusGraph会自动将顶点和类型转换为新的事务范围

graph = JanusGraphFactory.open("berkeleyje:/tmp/janusgraph")juno = graph.addVertex() //**Automatically opens a new transaction**graph.tx().commit() //Ends transactionjuno.property("name", "juno") //**Vertex is automatically transitioned**

graph中edge不会自动转换，也不能在外部访问。因此，必须进行明确转移

e = juno.addEdge("knows", graph.addVertex())graph.tx().commit() //Ends transactione = g.E(e).next() //Need to refresh edgee.property("time", 99)

1. Transaction Failures（事务提交失败）
   由于在执行过程中可能出现IO exceptions, network errors, machine crashes or resource unavailability等问题，因此建议在代码中进行异常处理：

     try {    if (g.V().has("name", name).iterator().hasNext())        throw new IllegalArgumentException("Username already taken: " + name)    user = graph.addVertex()    user.property("name", name)    graph.tx().commit()} catch (Exception e) {    //Recover, retry,   or return error message    println(e.getMessage())}

可能会导致事务失败的永久性异常包括：    PermanentLockingException（本地锁争用）：另一个本地线程已被授予冲突的锁。    PermanentLockingException（X的期望值不匹配：expected = Y vs actual = Z）另一个事务在读取和修改之后修改了这个值

1. Multi-Threaded Transactions（多线程事务）

 threadedGraph = graph.tx().createThreadedTx(); threads = new Thread[10]; for (int i=0; i<threads.length; i++) {    threads[i]=new Thread({        println("Do something with 'threadedGraph''");    });    threads[i].start(); } for (int i=0; i<threads.length; i++) threads[i].join(); threadedGraph.tx().commit();

1. Concurrent Algorithms（并发算法）
2. Nested Transactions（嵌套事务）
   第一种：

     v1 = graph.addVertex()//Do many other thingsv2 = graph.addVertex()v2.property("uniqueName", "foo")v1.addEdge("related", v2)//Do many other thingsgraph.tx().commit() // This long-running tx might fail due to contention on its uniqueName lock

第二种：

v1 = graph.addVertex()//Do many other thingstx = graph.tx().createThreadedTx()v2 = tx.addVertex()v2.property("uniqueName", "foo")tx.commit() // Any lock contention will be detected herev1.addEdge("related", g.V(v2).next()) // Need to load v2 into outer transaction//Do many other thingsgraph.tx().commit() // Can't fail due to uniqueName write lock contention involving v2

1. Common Transaction Handling Problems（常见的事务处理问题）

v = g.V(4).next() // Retrieve vertex, first action automatically starts transactiong.V(v).bothE()>> returns nothing, v has no edges//thread is idle for a few seconds, another thread adds edges to vg.V(v).bothE()>> still returns nothing because the transactional state from the beginning is maintained

v = g.V(4).next() // Retrieve vertex, first action automatically starts transactiong.V(v).bothE()graph.tx().commit()//thread is idle for a few seconds, another thread adds edges to vg.V(v).bothE()>> returns the newly added edgegraph.tx().commit()

1. Transaction Configuration（事务配置）

buildTransaction()返回一个TransactionBuilder它允许配置事务的以下方面：readOnly() - 使事务只读，任何修改图形的尝试都将导致异常。enableBatchLoading() - 为单个交易启用批量加载。storage.batch-loading由于禁用一致性检查和其他优化，此设置的结果与图形范围设置的效率类似。不像storage.batch-loading这个选项不会改变存储后端的行为。setTimestamp(long) - 将此事务的时间戳设置为传递到存储后端以进行持久化。根据存储后端，此设置可能会被忽略。对于最终一致的后端，这是用于解决写入冲突的时间戳。如果未明确指定此设置，则JanusGraph将使用当前时间。setVertexCacheSize(long size) - 这个事务在内存中缓存的顶点数量。数字越大，事务可能消耗的内存就越多。如果这个数字太小，一个事务可能不得不重新获取数据，导致长时间运行事务的延迟。checkExternalVertexExistence(boolean) - 这个事务是否应该验证用户提供的顶点ID的顶点的存在。这种检查需要访问需要时间的数据库。只有当用户确定顶点必须存在时才应该禁用存在检查 - 否则会导致数据损坏。checkInternalVertexExistence(boolean) - 此事务是否应在查询执行期间仔细检查顶点的存在。这对避免最终一致的存储后端上的幻像顶点很有用。默认情况下禁用。启用此设置可能会减慢查询处理速度。consistencyChecks(boolean) - JanusGraph是否应该执行模式级一致性约束（例如多重约束）。禁用一致性检查会提高性能，但要求用户确保应用程序级别的一致性确认，以避免不一致