簡単な要約
最新の Titan-0.5 スナップショットを使用。私たちのコードは、並行スレッドで頂点を作成します。同じキーを持つ複数の頂点がある状態になってしまいます。制約により、これは発生しないと予想されます。
以下を使用してキーを構成します。
PropertyKey name = management.makePropertyKey(keyName)
.dataType(String.class)
.cardinality(Cardinality.SINGLE)
.make();
TitanGraphIndex nameIndex = management.buildIndex(keyName, Vertex.class)
.indexKey(name)
.unique()
.buildCompositeIndex();
management.setConsistency(nameIndex, ConsistencyModifier.LOCK);
フルストーリー
一意の頂点プロパティ キーで構成された Titan DB があります。同時スレッド内で DB に書き込むと、Titan が同じキーで複数の頂点を保持していることがわかります。
問題を 1 つのテスト ファイルに まとめ ました。
このコードは 3 つのスレッドを生成します。これらのスレッドは、カウントダウン ラッチを介して (可能な限り) 同時に開始するように同期されます。キー「KEY_VALUE_A」で頂点を作成する キー「KEY_VALUE_B」で頂点を作成する 2 つのスレッドの間にラベルを作成する スレッドが順次実行される場合、キーの重複による例外が予想されます。私はこの事件を強制することができました。
スレッドが同時に実行される場合、少なくとも 1 つのスレッドが成功し、任意の数のスレッドが失敗することが予想されます。とにかく、グラフの最終状態は 2 つの頂点と、2 つの間の 1 つのエッジになると予想しています。
残念ながら、これを実行すると、DB は繰り返し 2 つ以上の頂点とエッジを持つ状態のままになります。キーが重複している頂点があります。テストは、グラフを XML にダンプします。例: https://gist.github.com/ubit-ee/d5530e4fa4b87c752294
テスト コードは berkeleydb 用に構成されていますが、Cassandra に対しても同じ問題を繰り返しました。
質問
- 頂点キーが一意になるように、スキーマを正しく構成しましたか?
- トランザクションで何か違うことをする必要がありますか?
- Titan の予想される動作を誤解していますか?