2

JENA を使用して、次のコードでトリプル ストア (TDB 機能) を作成しています。

public void createTDBFromOWL() {
    Dataset dataset = TDBFactory.createDataset(newTripleStoreLocation);

    dataset.begin(ReadWrite.WRITE);

    try {
        //getting the model inside the transaction
        Model model = dataset.getDefaultModel();
        FileManager fileManager=FileManager.get();
        Model holder=fileManager.readModel(model, newOWLFileLocation);

        //committing dataset
        dataset.commit();

        model.close();
        holder.close();
    } finally {
        dataset.end();
        dataset.close();
    }

}

トリプル ストアを作成した後、作成されたファイルはアプリケーション サーバー (Glassfish) によってロックされ、Glassfish を手動で停止してロックを解除するまでファイルを削除できません。上記のコードに示されているように、すべてを閉じていると思うので、ファイルのロックが維持される理由がわかりません。

4

1 に答える 1

3

を呼び出すDataset#close()と、実装はその呼び出しを基 DatasetGraphBase#close()になる に委譲し、最終的には に委譲しDatasetGraphTDB#_close()ます。

これにより、 および が呼び出されTripleTable#close()ますQuadTable#close()。これらは両方とも (いくつか) を呼び出しますNodeTupleTable#close()。間接化を続けると、これはNodeTable#close()and を呼び出しますTupleTable#close()。前者はインターフェースであるため、実装でどのクラスが実行されているかを適切に推測する必要があります。後者は、TupleIndexオブジェクトのコレクションを繰り返し処理し、それぞれを呼び出しclose()ます。TupleIndexもインターフェースです。

TupleIndexその結果、ファイルをロックできる何かが発生する子孫の意味のある階層が 1 つだけあり、 TupleIndexRecord#close(). 次に、実際の所有者が表示されるまで、RangeIndexcalledの特定の実装をたどることができます。BPlusTreeMappedByteBuffer

最終的に、 の実装を読んでいるとBlockAccessMapped#close()、階層全体が最終的なクラスに至るまで適切に閉じているように見えますが、この長年のバグが原因である可能性があります。ドキュメントから：

ファイルがマップされると、そのファイルに対する多くの操作は、マッピングが解放されるまで失敗します (たとえば、削除、マップされた領域よりも小さいサイズへの切り捨て)。しかし、プログラマーはマッピング解除が行われる時間を正確に制御することはできません --- 通常、それはファイナライズまたは PhantomReference キューの処理に依存します。

それで、あなたはそれを持っています。Jena の最善の努力にもかかわらず、そのファイルがいつ Java でアンマップされるかを制御することはまだできません。これは、Java でのメモリ マップド ファイル IO のトレードオフになります。

于 2014-04-17T14:30:11.547 に答える