[
https://issues.apache.org/jira/browse/JENA-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032841#comment-15032841
]
A. Soroka commented on JENA-624:
--------------------------------
No, no test, because I thought it pretty obvious, but I can certainly add one,
later this week.
I'm not sure what you mean by the question about {{::abort}}.
{{DatasetGraphInMemory::abort}} specifically changes the transaction tracking
state and calls {{DatasetGraphInMemory::end}}. That's just for DRY-ness. The
things that need to happen in an abort are local state cleanup (releasing the
dataset lock and so forth) and passing the message onto the various tuple
tables, so they can drop whatever state was associated to the transaction (in
the default impl, the "evolved" references to the data structures).
I understand {{end}} also to possess the semantic of "clean up and release any
state associated to the transaction". Is that not so? That's why I reused
{{end}} to do the same work as part of {{abort}}. See
{{DatasetGraphWithLock::_abort}} for what I think is the same pattern.
> 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)
