Hi Rupert, Your findings sound quite serious to me. From a quick check I can confirm your findings. It seems TDB backed read-only Graphs are in fact in-memory SimpleTripleCollections. I didn't implement this functionality originally so I am not an authority on it though ;)
About the problem of the MGraph's getGraph method: Intuitively I would approach the problem by creating a Wrapper (Decortator) for MGraphs that returns a "Immutable" Graph. This would return a Graph to the user that forwards read-access to the MGraph and prevents write access. However the backing graph will be an MGraph. In general: I don't know much about TDB's inner workings, does it offer read-only graphs? And if so what are the benefits of using them? (I assume more efficient synchronization). If there is such a thing, implementing native access to TDBs read-only graphs is definitely something great. Daniel On 20 March 2012 09:49, Rupert Westenthaler <[email protected]>wrote: > Hi again > > Just noticed that the > "org.apache.clerezza.rdf.jena.storage.JenaGraphAdaptor" does the exact same > by extending "org.apache.clerezza.rdf.core.impl.AbstractMGraph". > > This means that all Graphs returned by the Jena TDB provider > (org.apache.clerezza.rdf.jena.tdb.storage.TdbTcProvider) are in fact > in-memory copies. This would not be necessary as the TdbTcProvider already > ensures that a Graph can not be opened as MGraph. > > To avoid such copies one would need to refactor the JenaGraphAdaptor so > that one can create both a "JenaMGraphAdaptor" and a read-only > "JenaGraphAdaptor". JenaMGraphAdaptor.getGraph() would still need to create > an in-memory copy, but the "JenaGraphAdaptor" would allow to avoid this. > TcProvider implementations that instantiate ""JenaGraphAdaptor" would need > to ensure themselves that the underlining JenaGraph is not modified. > > This is of special importance to the SingleTdbDatasetTcProvider as I am > planing to add support for exposing the "urn:x-arq:UnionGraph" via the > TcProvider.getGraph(..) method. Creating in-memory copies of the union > graph over all named models within the TDB store is not feasible. > > best > Rupert > > > On 20.03.2012, at 08:42, Rupert Westenthaler wrote: > > > Hi all, > > > > While working on the SingleTdbDatasetTcProvider I noticed that the > > > > PrivilegedMGraphWrapper#getGraph() > > > > calls > > > > public Graph getGraph() { > > return new SimpleGraph(this); > > } > > > > If I am right this causes an in-memory copy of the the wrapped MGraph to > be created. Is there a special reason for that or should that? > > > > I would rather expect an PrivilegedGraphWrapper wrapping the graph > returned by the wrapped MGraph to be returned. Something like. > > > > public Graph getGraph() { > > return AccessController.doPrivileged(new > PrivilegedAction<Graph>() { > > > > @Override > > public Graph run() { > > return new > PrivilegedGraphWrapper(wrapped.getGraph()); > > } > > }); > > } > > > > Maybe one would even like to have only a single PrivilegedGraphWrapper > that is created on the first call to getGraph() > > > > best > > Rupert > > > >
