arne-bdt commented on issue #1961:
URL: https://github.com/apache/jena/issues/1961#issuecomment-1900509461
@sszuev
Thank you very much for your benchmark- and test-suite! It helped me to find
a race condition in my code.
From my understanding, your tests and benchmarks are tailored for graphs
that remain stable when accessed concurrently by multiple threads. However, I'm
puzzled about their practicality without transaction support. For instance,
consider the following code snippet which lacks transactional context, leading
to no guaranteed consistency between successive method calls to the graph:
```
var verTriple = g.find(versionTriple.getSubject(),
versionTriple.getPredicate(), Node.ANY).next();
final var ver = (Integer)verTriple.getObject().getLiteralValue() + 1;
g.add(versionTriple.getSubject(), versionTriple.getPredicate(),
NodeFactory.createLiteralByValue(ver));
g.delete(verTriple);
```
In my branch,
[transactional](https://github.com/arne-bdt/concurrent-rdf-graph/tree/transactional),
I've incorporated a transaction context around your benchmark and test code
where it seemed fitting.
The wrapper is coded like this:
```
internal fun execInWriteTransaction(graph: Graph, runnable: Runnable) {
if(graph is Transactional) {
if(graph.isInTransaction) {
runnable.run()
return
}
graph.begin(ReadWrite.WRITE)
}
try {
runnable.run()
if(graph is Transactional) {
graph.commit()
}
} catch (e: Exception) {
if(graph is Transactional) {
graph.abort()
}
throw e
}
}
```
Below are my benchmark results for GRAPH_WRAPPER_TRANSACTIONAL and TXN_GRAPH:

They look pretty bad for GRAPH_WRAPPER_TRANSACTIONAL and do not match my
experience in real life scenarios.
Interestingly, except for one unit test, GRAPH_WRAPPER_TRANSACTIONAL
demonstrates commendable performance in all your tests.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]