On 23/07/14 14:21, Claude Warren wrote:
I have lots of moving parts but here goes an attempt at a description.
I have a dataset with multiple named graphs.
I am running a modified (reworked?) version of Fuseki -- Old version but
modified to use JAXB and provide some extra restful functionality to
support queries and jquery clients.
I have 2 threads running in a ScheduledExecutorService.
The Runnables those threads execute do some work (external rest calls) and
then update a named graph with the results. The Runnables have the dataset
and a resource. I start a transaction on the dataset and update the
resource. then commit.
To make things more difficult the resource is wrapped with an PA4RDF
annotated object.
Sounds like I need to change the process to send in the URI of the resource
and the model name so that I can get the object within the transaction.
"resource" here being a com.hp.hpl.jena.rdf.model.Resource?
Then, yes, the transaction needs to re-get the Resource as there is a
hidden model if you use any resource operations (Resource.get*,
Resource.add* etc).
While some uses should work (if you know the internals of Resource), it
looks like a bad idea.
----------------
Rambling:
An immediate reaction might be "transactions everywhere" (Jena3). But
there are also use cases for the Model API that don't care it would all
be a burden and migration cost. One model (no dataset in sight),
memory-backed, non-transactional use (common case - single threaded).
This ought to have a simple "create-use" style and adding suggested or
enforced transactions adds nothing except clutter.
I wonder if there could be a rebinding graph that lives across
transaction boundaries (c.f. DatasetGraphTransaction) but enforces
transction use once it has been used transactionally at least once.
One simplification we could make is "one model - one dataset". At the
moment a model (graph) can be in two+ general purpose datasets. (I
can't actually think of a good use for that but its technically possible.)
Andy
Thx,
Claude
On Wed, Jul 23, 2014 at 1:51 PM, Andy Seaborne <[email protected]> wrote:
On 23/07/14 11:37, Claude Warren wrote:
Are there any known issues mixing transactions on datasources and model
locks (e.g. model.enterCriticalSection(Lock.WRITE)) ?
No. Well, not known to me :-)
But I would hazard a guess you have encountered something.
Could you describe your setup? I get snippets from your emails but not an
overall picture.
Are you really trying to do multithreads inside one transaction?
Note - it is necessary to get the model inside a transaction and not use
it across transaction boundaries.
(It's very visible API change to fix this :-()
Andy
