Hi, AbstractCacheLoader.int looks like this: @Override public void init(CacheLoaderConfig config, Cache<?, ?> cache, Marshaller m) throws CacheLoaderException { this.marshaller = m; if (config == null) throw new IllegalStateException("Null config!!!"); this.cache = cache; } This sets the non-volatile fields marshaller and cache. AbstractCacheLoader.int is called by the thread that starts the CacheManager which is different from e.g. expiration thread or other application threads. Shouldn't we safely publish these fields by making them volatile?

What about the fields in the interceptors?

On 24 May 2010, at 16:28, Manik Surtani wrote: > > On 24 May 2010, at 13:41, Mircea Markus wrote: > >> Hi, >> >> AbstractCacheLoader.int looks like this: >> >> @Override >> public void init(CacheLoaderConfig config, Cache<?, ?> cache, Marshaller m) throws CacheLoaderException { >> this.marshaller = m; >> if (config == null) throw new IllegalStateException("Null config!!!"); >> this.cache = cache; >> } >> >> This sets the non-volatile fields marshaller and cache. AbstractCacheLoader.int is called by the thread that starts the CacheManager which is different from e.g. expiration thread or other application threads. Shouldn't we safely publish these fields by making them volatile? > > Fair point, it makes sense. > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I don't see any guarantee that the thread calling e.g. TxInterceptor.@Inject(which sets transactionLog) is same with the thread calling visitPutKeyValueCommand (which accesses transactionLog) - latter is user thread which we do not control (or at least async pool thread)

On 24 May 2010, at 16:35, Manik Surtani wrote: > > On 24 May 2010, at 14:32, Mircea Markus wrote: > >> What about the fields in the interceptors? > > Only if there is a @Stop associated with the interceptors that use those fields, IMO > >> >> On 24 May 2010, at 16:28, Manik Surtani wrote: >> >>> >>> On 24 May 2010, at 13:41, Mircea Markus wrote: >>> >>>> Hi, >>>> >>>> AbstractCacheLoader.int looks like this: >>>> >>>> @Override >>>> public void init(CacheLoaderConfig config, Cache<?, ?> cache, Marshaller m) throws CacheLoaderException { >>>> this.marshaller = m; >>>> if (config == null) throw new IllegalStateException("Null config!!!"); >>>> this.cache = cache; >>>> } >>>> >>>> This sets the non-volatile fields marshaller and cache. AbstractCacheLoader.int is called by the thread that starts the CacheManager which is different from e.g. expiration thread or other application threads. Shouldn't we safely publish these fields by making them volatile? >>> >>> Fair point, it makes sense. >>> >>> -- >>> Manik Surtani >>> manik(a)jboss.org >>> Lead, Infinispan >>> Lead, JBoss Cache >>> http://www.infinispan.org >>> http://www.jbosscache.org >>> >>> >>> >>> >>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev