JanusGraph之Transactions

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

Transactional Scope（事务作用域）

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

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

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

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

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）另一个事务在读取和修改之后修改了这个值

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();

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

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

第二种：

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

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

v = g.V(4).next() // Retrieve vertex, first action automatically starts transaction
g.V(v).bothE()
>> returns nothing, v has no edges
//thread is idle for a few seconds, another thread adds edges to v
g.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 transaction
g.V(v).bothE()
graph.tx().commit()
//thread is idle for a few seconds, another thread adds edges to v
g.V(v).bothE()
>> returns the newly added edge
graph.tx().commit()

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是否应该执行模式级一致性约束（例如多重约束）。禁用一致性检查会提高性能，但要求用户确保应用程序级别的一致性确认，以避免不一致

JanusGraph之Transactions

猜你喜欢