On 08/06/15 20:38, aj...@virginia.edu wrote:
So to be clear, part of the idea here is to "boost" the visibility of
transactions, and one of the things that wants doing as part of that
is to provide for copy-on-add-graph semantics for the in-memory
dataset so that transactionality is coherent across such a dataset.
Right now it instead is a sort of patchwork of whatever forms of
transactionality were available in the graphs that have been added to
it, which isn't an attractive thing to advertise, and may not even
really work all the time.
less - there is no transactionality across the contained graphs.
(Model.graph transactions aren't connected to dataset transactions)
As far as model-as-views-of-datasets: is it true that all that is
needed for this is a good in-memory dataset?
It would be useful for working in-memory. For example default union
graph can bne made to work efficiently, as can dataset transactions.
What about datasets that
are much too large for memory? Or impls of Dataset that incur network
latency in operation? Or do these cases just imply the need for the
right kinds of laziness in views on Datasets?
Models from TDB are already views.
public class GraphTDB extends GraphView ...
Andy
--- A. Soroka The University of Virginia Library
On Jun 8, 2015, at 3:23 PM, Andy Seaborne <a...@apache.org> wrote:
On 08/06/15 10:25, Claude Warren wrote:
What exactly is this review asking? Change in strategy or change
in docs?
Both :-)
concurrency-howto does not mention transactions except in passing.
It shoudl be more pro-transactions IMO.
A possibility is that Dataset are all transactional, even is that
is only DatasetGraphWithLock;
No Dataset.supportsTransactions - its always true. Remove
Dataset.getlock.
concurrency-howto would be for model-only use. Everything else is
transaction in style. The documentation should reflect this
preferred style.
If we had (hi ajs6f!) an in-memory dataset as well as the general
container one, and the in-memory one were transactional, copy-in
for addGraph, we could make models be views of datasets always.
Creating a model would have an implicit Dataset if a free standing
model.
Andy
On Fri, Jun 5, 2015 at 8:30 PM, Andy Seaborne (JIRA)
<j...@apache.org> wrote:
Andy Seaborne created JENA-957:
----------------------------------
Summary: Review concurrency howto in the light of
transactions. Key: JENA-957 URL:
https://issues.apache.org/jira/browse/JENA-957 Project: Apache
Jena Issue Type: Bug Reporter: Andy Seaborne Priority: Minor
http://jena.apache.org/documentation/notes/concurrency-howto.html
Include {{DatasetGraphWithLock}}.
Consider if that should be the default for in-memory and
general datasets.
-- This message was sent by Atlassian JIRA (v6.3.4#6332)
