[
https://issues.apache.org/jira/browse/JENA-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033364#comment-15033364
]
Andy Seaborne commented on JENA-624:
------------------------------------
{{end}} is clean up once not everytime it is calls. See
{{DatasetGraphWithLock::_end()}} checks.
{{DatasetGraphInMemory.end}} can be called repeatedly but it is done without
transaction state checking.
Consider:
{noformat}
begin
try {
commit
end
} finally {
end
}
{noformat}
{{commit}} calls {{end()}} internally but written explicitly here.
The first {{end()}} clears the system transaction state and then releases the
MR+SW lock, but so does the second.
This sequence looks dangerous:
{noformat}
Thread 1 Thread 2
begin(W1)
commit
end/1
begin(W2)
end/2
{noformat}
I suspect that {{end/2}} aborts W2. I don't see any step that related to
threads the last statement of {{end()}}.
It might just need:
{noformat}
if (!isInTransaction())
return;
{noformat}
{noformat}
@Override
public void end() {
if (!isInTransaction())
return;
quadsIndex().end();
defaultGraph().end();
isInTransaction(false);
transactionType(null);
getLock().leaveCriticalSection();
}
{noformat}
> Develop a new in-memory RDF Dataset implementation
> --------------------------------------------------
>
> Key: JENA-624
> URL: https://issues.apache.org/jira/browse/JENA-624
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Andy Seaborne
> Assignee: A. Soroka
> Labels: java, linked_data, rdf
>
> The current (Jan 2014) Jena in-memory dataset uses a general purpose
> container that works for any storage technology for graphs together with
> in-memory graphs.
> This project would develop a new implementation design specifically for RDF
> datasets (triples and quads) and efficient SPARQL execution, for example,
> using multi-core parallel operations and/or multi-version concurrent
> datastructures to maximise true parallel operation.
> This is a system project suitable for someone interested in datatbase
> implementation, datastructure design and implementation, operating systems or
> distributed systems.
> Note that TDB can operate in-memory using a simulated disk with
> copy-in/copy-out semantics for disk-level operations. It is for faithful
> testing TDB infrastructure and is not designed performance, general in-memory
> use or use at scale. While lesson may be learnt from that system, TDB
> in-memory is not the answer here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
