I ran some tests for ACID using SPARQL update via the .../statements endpoint.

e.g. curl -H "Accept: application/sparql-results+json" -s --data-urlencode update@startcount.sparql http://localhost:8080/openrdf-sesame/repositories/test3/statements

I used a jmeter test harness with initialization script:

delete { ?a sys:count1 ?m ; sys:count2 ?n . } insert { ?a sys:count1 0 ; sys:count2 0 . } where { ?a rdf:type / rdfs:subClassOf * sys:AppIndividual . OPTIONAL { ?a sys:count1 ?m } OPTIONAL { ?a sys:count2 ?n } }

and update script (run multiple times on concurrent threads)

delete { http://syapse.com/based#${APPIND} sys:count1 ?n ; sys:count2 ?m . }
insert { http://syapse.com/based#${APPIND} sys:count1 ?nn ; sys:count2 ?mm . } where { BIND ( http://syapse.com/based#${APPIND} as ?a ) http://syapse.com/based#${APPIND} sys:count1 ?n; sys:count2 ?m . BIND ( ?n + 1 as ?nn ) BIND ( ?m +1 as ?mm ) }

and verification script:

ask { ?a rdf:type / rdfs:subClassOf * sys:AppIndividual . OPTIONAL { ?a sys:count1 ?n } OPTIONAL { ?a sys:count2 ?m } FILTER ( !bound(?m) || !bound(?m) || ?n != ?m ) }

Unfortunately, the last query returns true ....

Have I misconfigured my system, or is this a defect with OWLIM?



asked 23 May '13, 16:15

jeremycarroll's gravatar image

accept rate: 0%

Hi Jeremy, thanks for reporting this.

There is a method for relaxing isolation in OWLIM, but this is not default behaviour and you have to deliberately set this up with two configuration parameters as follows:

transaction-mode = "FAST"
transaction-isolation = "false"

Unless you have done this, then you are unlikely to have configured OWLIM incorrectly.

Just to make sure I understand the test case, you have lots of instances of sys:AppIndividual and sub-classes and these have two count values associated with them. The update script increments both these counters for instance values substituted into "http://syapse.com/based#${APPIND}"

It would be most useful to know what values cause the verification query to fail. Is it possible to execute:

select * { ?a rdf:type / rdfs:subClassOf * sys:AppIndividual .
    OPTIONAL { ?a sys:count1 ?n }
    OPTIONAL { ?a sys:count2 ?m }
    FILTER ( !bound(?m) || !bound(?m) || ?n != ?m )

You have probably checked this, but does your verification query return false before you start the concurrent updates?

In any case, we will investigate further to see what is going on here....


answered 29 May '13, 06:06

baz's gravatar image

baz ♦♦
accept rate: 36%

I left transaction-isolation as true, and replicated the issue with transaction mode either safe or fast.

The initial version always modified the values on a single AppIndividual (because I hadn't implemented the round robin!); and this fails; having implemented round robin, it still fails.

I did try the query above after a test run and while I don't have the exact values it was something like ?n = 80 and ?m = 20.

It is plausible that jmeter uses the same HTTP 1.1 connection for multiple requests, so maybe that resulted in OWLIM putting more than one update in the same transaction.

(29 May '13, 13:26) jeremycarroll
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: 23 May '13, 16:15

Seen: 1,724 times

Last updated: 29 May '13, 13:26

powered by BitNami OSQA