You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Claude Warren <cl...@xenei.com> on 2014/07/23 12:37:45 UTC
transactions and model locks.
Are there any known issues mixing transactions on datasources and model
locks (e.g. model.enterCriticalSection(Lock.WRITE)) ?
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: transactions and model locks.
Posted by Andy Seaborne <an...@apache.org>.
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 <an...@apache.org> 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
>>
>>
>
>
Re: transactions and model locks.
Posted by Claude Warren <cl...@xenei.com>.
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.
Thx,
Claude
On Wed, Jul 23, 2014 at 1:51 PM, Andy Seaborne <an...@apache.org> 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
>
>
--
I like: Like Like - The likeliest place on the web
<http://like-like.xenei.com>
LinkedIn: http://www.linkedin.com/in/claudewarren
Re: transactions and model locks.
Posted by Andy Seaborne <an...@apache.org>.
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