Hello Andy,
sorry for my very, very late answer. We rolled out many new features on
our platform in the last weeks, so I was too busy to integrate our TDB
0.8.10 changes to TDB 0.9. Yesterday I started again.
Our unit tests print out a ConcurrentModificationException if we iterate
over the model's statements (read transaction) and update the model in
another thread (write transaction) concurrently. I could imagine that is
is an intended functioning, but I'm not sure. We generally operate on
the model using the following pattern:
public static <T> T doWork(int id, final boolean writeAccess,
StoreWork<T> work) throws Exception {
Dataset set=newDataset(id);
set.begin(writeAccess ? ReadWrite.WRITE : ReadWrite.READ);
try {
T result=work.execute(id, set.getDefaultModel());
set.commit();
return result;
} catch (Exception e) {
set.abort();
throw e;
} finally {
set.end();
}
}
where id is the ID of the graph we want to access and work.execute does
the actual work on the model. I hope we use the transaction framework
correctly.
Do you know if the iterator behaviour above is intended?
Best wishes
André
On 13.11.2012 21:49, Andy Seaborne wrote:
On 13/11/12 12:26, "Dr. André Lanka" wrote:
Hi Andy,
On 12.11.2012 18:21, Andy Seaborne wrote:
Is each store using named graphs? Or is one store, one graph?
One store is one default graph without any special named graphs along.
The reason for having multiple stores is that we need write access to
each graph in parallel. Serialising the write access would lead to poor
performance for our application. By having multiple stores, we can write
to each store independent of the current state of the other stores. I
assume that this would also be a problem when we use dynamic datasets.
Or is there something I missed again?
No - that's a reasonable setup, in fact one of the few I can think of
for multiple stores each with one graph.
I look forward to the patch,
Andy
Best wishes
André
--
Dr. André Lanka * 0178 / 134 44 47 * http://dr-lanka.de
