Applied - thanks.
Rational the startRead can increment the counter in the policy and
then throw a concurrent modification exception, this needs to be
matched in that case by the finishRead()
BTW
TDB 0.9 supports transactions. This sort of CCME is not possible when
using transactions which support multiple readers *and* a single writer
concurrently as well as readers from previous generations of database,
which see a consistent view. It's isolation level "serialized".
("is not" == "should not" of course, but judging by your other emails
you are not using transactions).
Andy
On 16/08/12 06:28, Jeremy Carroll wrote:
OLD:
@Override
public Iterator<Tuple<NodeId>> find(NodeId... ids)
{
Tuple<NodeId> tuple = Tuple.create(ids) ;
startRead() ;
try {
return find(tuple) ; // **public call
} finally { finishRead() ; }
}
SHOULD BE:
@Override
public Iterator<Tuple<NodeId>> find(NodeId... ids)
{
Tuple<NodeId> tuple = Tuple.create(ids) ;
try {
startRead() ;
return find(tuple) ; // **public call
} finally { finishRead() ; }
}
Lines 151 to 159.
Rational the startRead can increment the counter in the policy and then
throw a concurrent modification exception, this needs to be matched in
that case by the finishRead()
Jeremy
