Transaction Handling

• Every graph operation in JanusGraph occurs within the context of a transaction. According to the TinkerPop’s transactional specification, each thread opens its own transaction against the graph database with the first operation (i.e. retrieval or mutation) on the graph:

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

• Janusgraph的事務(wù)通常不是ACID的，當(dāng)存儲后端是BerkeleyDB時這樣配置問題不大。但是當(dāng)存儲后端是Cassandra，hbase時，通常不支持ACID, 因為他們不支持串行隔離或者多行的原子寫操作，如果要讓janusgraph上層在這種存儲后端下支持ACID屬性，代價非常昂貴，需要使用分布式鎖來實現(xiàn)。

• hbase，Cassandra只可以保證行（row)級別的原子性，如果一個操作涉及到多行數(shù)據(jù)的操作，那么habase/c無法保證操作該操作的原子性。

• janusgraph頂點的屬性，邊信息都存儲在要給row中，所以一個頂點的多線程操作在hbase上時可以保證ACID中的C。如果涉及到多個頂點的操作要想保證C那么要用分布式鎖，當(dāng)然同時也保持了A.

Transactional Scope

• 圖元素（vertices, edges, and types）具有事務(wù)作用域，一個事務(wù)被關(guān)閉后（commit() or rollback().），圖元素就過時和不可以訪問了。
• 不過頂點、類型元素會被自動轉(zhuǎn)移到新的事務(wù)中。但是邊就不會自動轉(zhuǎn)移到新事物，其必須顯示轉(zhuǎn)移：對應(yīng)的操作是g.E(e).next()。

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

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

• 但是對于在Multi-Threaded Transactions（下面介紹）的元素，一旦事務(wù)關(guān)閉，都需要顯示刷新，對應(yīng)操作：g.V(existingVertex) 和g.E(existingEdge).

• 如果A事務(wù)中查詢一個頂點的邊沒查到，此時B事務(wù)中為該頂點添加了邊并提交成功，那么A在沒有提交的情況下再次查詢頂點的邊依舊查不到。所以在一個操作完成后提交事務(wù)是很有必要的。

Transaction Failures

• 對于Potentially temporary failures（一般由IO擁堵、網(wǎng)絡(luò)超時造成） ，JanusGraph 會在稍后自動重試，重試的次數(shù)和稍后時間可通過配置文件配置。

• Permanent exceptions ：造成原因連接斷開connection loss 、硬件損壞 hardware failure、鎖競爭lock contention。

  • 鎖競爭： 比如修改在一個開啟的事務(wù)中修改name為zhouliang，但是在事務(wù)提交時，該name的鎖被另一個事務(wù)獲得，此時就會產(chǎn)生鎖競爭，導(dǎo)致另一個事務(wù)失敗。在鎖競爭中失敗的事務(wù)會重新運行整個事務(wù)從而從失敗中恢復(fù)。

• Permanent exceptions that can fail a transaction include:

  • PermanentLockingException(Local lock contention): Another local thread has already been granted a conflicting lock.
  • PermanentLockingException(Expected value mismatch for X: expected=Y vs actual=Z): The verification that the value read in this transaction is the same as the one in the datastore after applying for the lock failed. In other words, another transaction modified the value after it had been read and modified.

Multi-Threaded Transactions

• 多線程事務(wù)：支持多個線程在同一個事務(wù)中并發(fā)操作同一個圖對象，從而提供事務(wù)處理能力和利用多核架構(gòu)。

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

• 最后一個線程運行完成后，事務(wù)就會提交。
• The method newTransaction is used to start multi-threaded transactions only.
• JanusGraph.buildTransaction() method gives the user the ability to configure and start a new multi-threaded transaction against a JanusGraph
  .

Nested Transactions

• 嵌入事務(wù)：不同于上面的環(huán)繞事務(wù)（一個事務(wù)環(huán)繞多個線程）
• 需求：一個事務(wù)中執(zhí)行時間很長，并且有添加節(jié)點with a unique name操作，為了保證name唯一，所以需要通過鎖來實現(xiàn)，正如上面的“鎖競爭”問題，如果一個事務(wù)中執(zhí)行時間很長，又有添加唯一名稱頂點操作，所以在最后提交事務(wù)時很容易失敗。想法：針對添加唯一名稱頂點操作，可以在整個事務(wù)中通過一個嵌套事務(wù)來完成。

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

Transaction Configuration

• 用于調(diào)節(jié)事務(wù)