[
https://issues.apache.org/jira/browse/JENA-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15809288#comment-15809288
]
Andy Seaborne commented on JENA-1274:
-------------------------------------
Looks interesting!
GH does not make discussions of branches as easy as PRs (I have just
discovered!). It is possible to PR a branch on the codebase it is a branch of.
I'm not clear what the background for this is.
I don't want to wrongly guess the pros and cons of various approaches. Could
you say some more about what the usage is compared to, say, one dataset per
resource, only use the default graph (which is not the same, but is one LDP
setup)? About whether "default union graph" may be in use?
Isn't the contract "One writable graph per txn" rather than "per-graph writer"?
"getGraph" seems to throw an exception if a second graph is touched.
A generalization is 2-phase locking (2PL) on graphs. Each time "getGraph" is
called in a transaction, a lock is taken and the write lock set for this
transaction grows. Keepa global lock set as well. Then check if the graph is
locked by another transaction and abort (deadlock has just occured). Write
locks are kept until the end of transaction, not released part way through -
this is 2PL and has well defined properties about deadlock. The serialization
level across the dataset is read-commited.
This leads to another question/area - how does this play out if sometimes its
LDP-style mixed with whole dataset style operations: e.g. SPARQL {{COPY GRAPH
<G1> INTO GRAPH <G2>}} or the API sequence: {{model1.add(model2)}}, in graph
SPI terms: {{GraphUtil.addInto(graph1, graph2) ;}}?
> Support a writer-per-graph in-memory dataset
> --------------------------------------------
>
> Key: JENA-1274
> URL: https://issues.apache.org/jira/browse/JENA-1274
> Project: Apache Jena
> Issue Type: Improvement
> Components: ARQ, Jena
> Reporter: A. Soroka
> Assignee: A. Soroka
> Priority: Minor
> Labels: ldp, multithreading, named_graphs
>
> Without too much work we could support a writer-per-graph in-memory dataset.
> The target use case here is LDP-style interaction or other RESTful
> architectures, where it is normal for updates to occur centered on one
> resource.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
