jena-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: IRIResolver cache not thread safe?
Date Mon, 14 Nov 2011 22:10:55 GMT
On 14/11/11 20:20, Simon Helsen wrote:
> Andy,
>
> thanks, I was digging through the code paths both in the latest as well
> as the version we currently still have deployed (arq 2.8.5) and it seems
> that the only difference is that in 2.8.5, the readImpl of JenaReadRIOT
> calls the resolve here:
>
> *private**void*readImpl(Model model, Tokenizer tokenizer, String base)
> {
> // The reader has been checked, if possible, by now or
> // constructed correctly by code here.
> *if*( base != *null*)
> base = IRIResolver./resolveGlobalToString/(base) ;
> *try*{
> model.notifyEvent( GraphEvents./startRead/);
> readWorker(model, tokenizer, base) ;
> }
> ...
> whereas in the latest, there is no resolution of the base at all at that
> stage:
>
> *private**void*readImpl(Model model, Tokenizer tokenizer, String base)
> {
> *try*{
> model.notifyEvent( GraphEvents./startRead/);
> readWorker(model, tokenizer, base) ;
> }
> ...
>
> Now, deeper down, both create an IRIResolverNormal object, so I am
> guessing it is safe if I patch our current version to remove the call to
> resolveGlobalToString. Any comments? (and before you ask, this is
> because we are currently not yet upgrading the jena stack, but I need to
> fix this since it leads to concurrency errors during our indexing process)
>
> thanks
>
> Simon

Better would be to patch IRIresolver and add "synchronized" to every 
static function that uses "globalResolver".  Deleting the code from 
readImpl means that you've change the behaviour of reading when the base 
is provided.  Maybe your code always sets an absolute base ... but safer 
to fix IRIResolver IMO.  I don't think globalResolver isn't let out of 
IRIResolver in v2.8.5

	Andy



Mime
View raw message