On 15/03/16 14:12, A. Soroka wrote:
I guess you could use addGraph to intercept and alter (or substitute) the graph,
Or
getGraph(graphNode)
but that seems like a real distortion of the semantics. Seems like the
AFS-Dev material is more to the point here.
Andy, what do you think it would take to get that stuff to Jena
master? Do you think it is ready for that? I would be happy to
refactor TIM to use it instead of the stuff it currently uses in
o.a.j.sparql.core.mem.
I don't think its ready - it has not been used "in anger" and it may be
the wrong design. It needs trying out outside the codebase. TIM works
as it currently so it isn't a rush to put it in there.
(digression:...)
I was at a talk recently about high performance java and the issue of
object churn was mentioned as being quite impactful on the GC as the
heap size grows. Once a long time ago, object creation was expensive
... then CPUS got faster and the java runtime smarter and it was less of
an issue ... but it seems that its returning as a factor
inline lambdas are apparently faster than the same code with a class
implementation - the compiler emits an invokedynamic for the lanmbda
and Java Stream can cause a lot of short-lived objects.
Andy
---
A. Soroka
The University of Virginia Library
On Mar 15, 2016, at 7:39 AM, Dick Murray <dandh...@gmail.com> wrote:
Eureka moment! It returns a new Graph of a certain type. Whereas I need the
graph node to determine where the underlying data is.
Cheers Dick.
On 15 March 2016 at 11:28, Andy Seaborne <a...@apache.org> wrote:
On 15/03/16 10:30, Dick Murray wrote:
Sorry, supportsTransactionAbort() in AFS-Dev
<https://github.com/afs/AFS-Dev>/src
<https://github.com/afs/AFS-Dev/tree/master/src>/main
<https://github.com/afs/AFS-Dev/tree/master/src/main>/java
<https://github.com/afs/AFS-Dev/tree/master/src/main/java>/projects
<https://github.com/afs/AFS-Dev/tree/master/src/main/java/projects>/dsg2
<https://github.com/afs/AFS-Dev/tree/master/src/main/java/projects/dsg2>/
*DatasetGraphStorage.java*
*Experimental code.*
supportsTransactionAbort is in the DatasetGraph interface in Jena.
DatasetGraphStorage is using TransactionalLock.createMRSW
As mentioned, it needs cooperation from the underlying thing to be able to
do aborts and MRSW does not provide that (it's external locking).
DatasetGraphStorage doesn't presume that the storage unit is transactional.
After these discussions I've decided to create a DatasetGraphOnDemand which
extends DatasetGraphMap and uses Union graphs.
However in DatasetGraphMap shouldn't getGraphCreate() be
getGraphCreate(Node graphNode) as otherwise it doesn't know what to
create?
It creates a graph - addGraph(graphNode, g) is managing the naming. Grapsh
don't know the name used (in other places one graph can have many names).
DatasetGraphMap is for a collection of independent graphs to be turned
into a dataset.
Andy
@Override
public Graph getGraph(Node graphNode)
{
Graph g = graphs.get(graphNode) ;
if ( g == null )
{
g = getGraphCreate() ;
if ( g != null )
addGraph(graphNode, g) ;
}
return g ;
}
/** Called from getGraph when a nonexistent graph is asked for.
* Return null for "nothing created as a graph"
*/
protected Graph getGraphCreate() { return null ; }
Dick.
