On 29/11/13 17:18, Billig, Andreas wrote:
Thanks Andy, I will take a look at scala-caching if I have free time.
Till then I conclude that the result order is the same between two write
transactions - is this right ?
Andreas
Within a read transaction, usually yes (unless you call RAND, NOW etc!)
even if a later write transaction starts. TDB read transaction are
serializable; there no lesser level needed. (You shouldn't really rely
on it though, other system may differ, but sometimes you have to.)
Andy
________________________________________
Von: Andy Seaborne [[email protected]]
Gesendet: Donnerstag, 28. November 2013 18:18
An: [email protected]
Betreff: Re: query evaluation determinism
On 28/11/13 11:32, Billig, Andreas wrote:
Hello Team,
we exploring the good old "offset-limit-sorted"-issue. therefore our
question: under which circumstances query evaluation is deterministic
regarding - the tdbstats-file - transactions, i.e. adding or deleting
triples
After a change, all bets are off. The exact internal order will depend
on what indexes were used and it's hard to predict how updates affect
that. If full sorted results, then the order of evaluation is as per
the ORDER BY.
Within a read transaction, you don't see any change.
resp. what we have to ensure if we want to have determinism - without
using 'sorted by'? resp. which operations destroy determinism?
thanks in advance, Andreas
There is this experimental code (which is in scala):
http://svn.apache.org/repos/asf/jena/Experimental/sparql-cache/
It looks at a query, and can remove the LIMIT/OFFSET. It caches the
result then reapplies the LIMIT/OFFSET. So next time , the query is
cached and it's just a slice.
Andy
