One writable graph per thread/transaction dataset

[ajs6f]

A pass at:

https://issues.apache.org/jira/browse/JENA-1274

[afs]

Immediate reaction: Why are the tests in "pergraph"?

If this is the beginning of "jena-ldp", do we want a package under src/main?

[ajs6f]

pergraph: Just thought that core was getting awfully crowded. I don't care one way or the other-- happy to put them anywhere.

jena-ldp: One of the questions I'm trying to raise with this PR is exactly that-- is this useful only for LDP-type workloads (in which case maybe it belongs outside ARQ entirely) or not (in which case it has more claim to be in ARQ)?

[asfbot]

Claude Warren on dev@jena.apache.org replies:
perhaps in extras?

[asfbot]

"A. Soroka" on dev@jena.apache.org replies:
Sure, that would be natural. Let me put the question this way: is a =
per-graph arrangement of this kind interesting to anyone who isn't =
interested in LDP?=20

The other direction here is forward with respect to locking. Claude and =
others (including me) have thrown around ideas on the list about how we =
could introduce more finely-grained locking for datasets, and I =
definitely think of this as a first tiny baby step in that direction.

---

A. Soroka
The University of Virginia Library
I
is
case
more
have your
feature
please
ticket

[asfbot]

Andy Seaborne on dev@jena.apache.org replies:
+1 to extras.

I think that has a lot of merit for small things to be in extras. It is
easier to point at and say "new - subject to change".

As does separate github repos - especiallty where the early status is
unstable, where access while being developed for a the most intersted
people is not affected by Jena release cycles.

that-- is this useful only for LDP-type workloads (in which case maybe
it belongs outside ARQ entirely) or not (in which case it has more
claim to be in ARQ)?

How about describing some use case where you think it might be helpful?

Just having something in the codebase does not really ask the question
you have about what might be - code tends to ask "does this exact thing
do ..."

 Andy

[ajs6f]

That's a really fair point about providing some use cases. An example that occurs to me is RDF-based persistence where Java entities are being saved into a dataset. I think @Claudenw has something like that going on in PA4RDF. This kind of dataset could act as a simple but powerful cache for that kind of system.

[ajs6f]

I will retarget this at jena-extras. It does make more sense.

[ajs6f]

It looks like in order to put this in jena-extras, I will need to create a new modules there. Any opinions about the name? Maybe jena-optional-datasets or something like that?

[afs]

Possible naming approaches:

1. "Small things" being curated go into a general jena-extras/jena-wip/jena-labs/jena-optional module with the idea that that is just while they mature, Downside: things go into that module and don't progress.
2. At the other end of the spectrum, this is a step for jena-ldp so to get attention on that, use that name. Downside: over selling.
3. Specific for this one thing: jena-writer-dsg, a name for the write-centric dataset. Downside: does not connect to LDP usage.

[ajs6f]

Yeah, judging by the general silence in response to my question about "Does anyone have other use cases for this kind of thing?" I'm not going to push on that I'm happy for it to be helpful to the LDP use case. But I don't want to oversell that either. I don't know that Jena would want to house an LDP impl or that I would want to do that here. Hm. Well, one question is whether we think that there ever would be a full-on jena-ldp?

[ajs6f]

I'm starting to wonder whether I should back up here and just go for the more general 2-phase-locking design as @afs discusses in the Jira ticket, or even to try to generalize to more amorphous locking regions. Doing those things would open up more use cases which might make this stuff viable for jena-arq itself.

[ajs6f]

Closing in favor of further more general discussion about points raised on this PR.