On 16/10/12 20:18, Simon Helsen wrote:
thanks Andy,
how can I track commits? I went to
http://svn.apache.org/viewvc?rev=1398525&view=rev, which allows me to look
at individual revision numbers, but can I subscribe to a mailing list
where the revisions are sent to? Or, can I use viewvc to just see the
commits to Jena components?
Simon
You can subscribe to the mailing list [email protected] (anyone
can). svn commits and Jenkins build failures get sent there.
It's archived as well:
http://mail-archives.apache.org/mod_mbox/jena-commits/
(it's not a very exciting mailing list!)
Andy
From:
Andy Seaborne <[email protected]>
To:
[email protected]
Date:
10/16/2012 08:08 AM
Subject:
Re: concurrent modification in BlockMgrJournal
On 15/10/12 22:38, Simon Helsen wrote:
thanks for the quick analysis. I am pretty sure there is no concurrent
access inside one active transaction (Our code doesn't do that kind of
thing). But we are using TDB's ability to insert a quad filter and
during
the query calculations, you escape to our registered filter which may on
its turn perform a graph find action. This is what you can see in the
stack trace, i.e. we enter ARQ in
com.hp.hpl.jena.sparql.engine.ResultSetStream.hasNext and Jena jumps
back
in org.openjena.atlas.iterator.RepeatApplyIterator.hasNext, which then
calls com.hp.hpl.jena.tdb.migrate.DatasetGraphTrackActive.find. However,
it all happens in one and the same thread.
Can you tell me what classes I need to look at? I will probably have to
backport and patch 2.7.1 for our earlier release based on that version.
I
would be able to provide a patch to our test team and have them restart
a
run
Simon
The changes are all in BlockMgrJournal: the commit email to
[email protected] has all the details - see below for a copy of
the start of that message which includes a link to the diff.
Re: quad filtering.
That does not cause this problem as it does not result in two threads in
Set<>.add.
Don't see why if shouldn't work, it's just like another read action
inside a transaction.
The filtering is applied outside the core index access code, (it filters
a NodeId binding iterator) so, to the TDB system, it looks just like
another read action during iteration of another read action which is fine.
Andy
Author: andy
Date: Mon Oct 15 21:10:21 2012
New Revision: 1398525
URL: http://svn.apache.org/viewvc?rev=1398525&view=rev
Log:
Only record read/readIterator blocks during a transaction.
Modified:
jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/transaction/BlockMgrJournal.java
Modified:
jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/transaction/BlockMgrJournal.java
URL:
http://svn.apache.org/viewvc/jena/trunk/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/transaction/BlockMgrJournal.java?rev=1398525&r1=1398524&r2=1398525&view=diff
