[infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

Sanne Grinovero sanne at infinispan.org
Wed Sep 14 11:53:52 EDT 2011


On 14 September 2011 17:37, Manik Surtani <manik at jboss.org> wrote:
>
> On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:
>> For example, I suspect that you won't be able to deploy an Hibernate
>> Search application (or Infinispan Query) and then deploy a Hibernate
>> OGM based application in the same container.
>> But this is not proven as I didn't try it out, so maybe my assumptions
>> about what the goal of this classloader parameter are wrong.
>
> Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.

Exactly the point. Unless you can make sure that both OGM and Search
are included in AS7 and special purpose caches are pre-configured out
of the box :-)

>
>> So I think that, iff we need to cache this information, it shouldn't
>> be cached in a static field, as discussed as well on
>
> Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?

Since caches can be started only once and should happen in the context
of a startCaches( ... ) context, such a cache could live in the scope
of such an invocation.
Besides solving the (potential?) problem that would also save some
memory as this information would be released right after usage.

I don't think people will be able to reuse the AS7 managed caches for
the purpose of Search or OGM, as for these reasons such extensions
should be available at AS7 boot-time, so we should at least make sure
that starting your own EmbeddedCacheManager is an option, otherwise
I'll be left with two options none of them viable.

Cheers,
Sanne



More information about the infinispan-dev mailing list