9:51 a.m.
Copying the dev list, which I should have done yesterday once I went far
beyond "Have you tagged Alpha2 yet/" :-)
Manik Surtani wrote:
On 10 Jan 2007, at 04:21, Brian Stansberry wrote:
> Have you tagged Alpha2 yet?
>
Yes but I got this patch in.
Thanks much. Lets me use it in the AS. :-)
> DefaultCacheFactory is making it impossible to properly construct
a
> cache from the microcontainer. Internally it's cloning the config,
> and Configuration.clone() is resetting the RuntimeConfig. This makes
> it impossible to build a Configuration+RuntimeConfig and then create
> a cache from it.
>
> I don't think the factory should clone configs, or at least should
> expose the flag that turns it off. The comments around it indicate a
> concern about different caches using the same Configuration and
> stepping on each other. IMHO, that's not a proper concern of the
> factory -- that's something that needs to be managed by the caller
> of the factory.
>
> TBH, I've kind of forgotten the purpose of the factory :-). The
> caches in the AS are all being instantiated by CacheJmxWrapper. I
> could easily replace the factory call there with one to new CacheImpl
> (Configuration).
:-) See http://jira.jboss.com/jira/browse/JBCACHE-930
We should force all cache and node instance creation to go
through the factory, so we have a dedicated layer where all
construction takes place.
OK. Definitely one way or the other is good -- factory but able to
directly construct was confusing. :P
> But that won't work for the Tomcat cache, which uses
PojoCache.
> PojoCache internally is using the DefaultCacheFactory to build its
> cache (Ben that's why I cc'd you.)
>
> So, possibilities I see are:
>
> 1) CacheJmxWrapper and PojoCache just call new CacheImpl
> (Configuration). 2) DefaultCacheFactory doesn't clone.
> 3) CacheFactory is changed to add a createCache method that exposes
> whether to clone. 4) Configuration.clone() doesn't call reset() on
> the RuntimeConfig. 5) RuntimeConfig.reset() only clears the
> NodeFactory field (I don't see why the other fields it clears need
> to be cleared).
>
I've gone with 5 instead, for the time being. Let's revisit
and fix this properly for BETA1.
Sounds good.
Just to clarify though, I was under the impression the
runtime configuration was generated by the cache, by
attaching various runtime subsystems that are built based on
the configuration XML such as the TM. The reason we exposed
it is so that such systems could be overridden/injected at
runtime by the MC. So it would just need to be a sequence of events
that change:
1) create cache
2) start cache
3) inject specific subsystems such as the TM
Does it not work this way with the MC?
No, the MC builds up the entire Configuration structure and then injects
it into the bean that instantiates the cache (bean is either a
CacheFactory instance or an instance CacheJmxWrapper, which internally
uses the CacheFactory).
In order to have the runtime objects available when needed, the sequence
would need to be:
1) Create config bean x- runtime objects
2) Use config to instantiate cache bean
3) Inject runtime objects into config bean
4) Call create() on cache bean
5) Call start() on cache bean
I don't see how the MC could possibly manage that sequence, since it
requires weaving together operations on 2 different beans (really 3
beans, since step #2 has a factory involved.) If we used
CacheJmxWrapper, and added properties to it for the runtime objects, it
could have that sequence hard coded, but that's a nasty hack.
The reason why I want to make sure we reset RuntimeConfig and
clone Configuration is if we have 2 cache instances in the
same JVM, we may need cache-specific instances of more than just the
NodeFactory.
OK, that's fine, but
1) reset() should limit itself to objects that are clearly meant to be
cache-specific (which is what you did w/ #5 above).
2) I don't think cloning the configuration is the responsibility of the
CacheFactory. It's the responsibility of the caller. As we explore use
cases for reusing configurations, we may come up with some classes that
help manage configurations for people, e.g. a ConfigurationFactory
similar to JChannelFactory. Those classes could be responsible for
cloning.
A problem here is TransactionManager, JChannelFactory and MBeanServer
are kind of neither fish nor fowl. They can reasonably be injected into
the cache and IMHO should be if the environment supports that. If the
environment doesn't support that, we have stuff like
TransactionManagerLookup to substitute for the missing IOC framework.
Another thing to consider is whether we want the cache to have the
ability to look up the multiplexer in JMX, or whether that becomes the
task of some other integration layer (e.g. CacheJmxWrapper) that updates
the Configuration and builds the cache. If we remove that from the
cache then:
a) JChannelFactory is only available from external injection -- i.e. the
cache doesn't add it to its own Configuration.
b) Not sure, but I think we don't need MBeanServer anymore.
That would leave only TransactionManager as the "neither fish nor fowl"
type.
- Brian
10:19 a.m.
New subject: Problems with DefaultCacheFactory
<SNIP />
> Just to clarify though, I was under the impression the
> runtime configuration was generated by the cache, by
> attaching various runtime subsystems that are built based on
> the configuration XML such as the TM. The reason we exposed
> it is so that such systems could be overridden/injected at
> runtime by the MC. So it would just need to be a sequence of events
> that change:
>
> 1) create cache
> 2) start cache
> 3) inject specific subsystems such as the TM
>
> Does it not work this way with the MC?
>
No, the MC builds up the entire Configuration structure and then
injects
it into the bean that instantiates the cache (bean is either a
CacheFactory instance or an instance CacheJmxWrapper, which internally
uses the CacheFactory).
In order to have the runtime objects available when needed, the
sequence
would need to be:
1) Create config bean x- runtime objects
2) Use config to instantiate cache bean
3) Inject runtime objects into config bean
4) Call create() on cache bean
5) Call start() on cache bean
I don't see how the MC could possibly manage that sequence, since it
requires weaving together operations on 2 different beans (really 3
beans, since step #2 has a factory involved.) If we used
CacheJmxWrapper, and added properties to it for the runtime
objects, it
could have that sequence hard coded, but that's a nasty hack.
Fair enough, I suspected it would be the case.
> The reason why I want to make sure we reset RuntimeConfig and
> clone Configuration is if we have 2 cache instances in the
> same JVM, we may need cache-specific instances of more than just the
> NodeFactory.
>
OK, that's fine, but
1) reset() should limit itself to objects that are clearly meant to be
cache-specific (which is what you did w/ #5 above).
2) I don't think cloning the configuration is the responsibility of
the
CacheFactory. It's the responsibility of the caller. As we
explore use
cases for reusing configurations, we may come up with some classes
that
help manage configurations for people, e.g. a ConfigurationFactory
similar to JChannelFactory. Those classes could be responsible for
cloning.
Fair enough as well, we would have to make sure this is clearly
documented. I'd still want to force a reset on the NodeFactory
though; a NodeFactory should not exist before a Cache does. Will
look into it for BETA1.
A problem here is TransactionManager, JChannelFactory and MBeanServer
are kind of neither fish nor fowl. They can reasonably be injected
into
the cache and IMHO should be if the environment supports that. If the
environment doesn't support that, we have stuff like
TransactionManagerLookup to substitute for the missing IOC framework.
Again, I see what you mean - an IOC framework is sorely missed, maybe
at some stage we ought to bring the MC into the JBC core.
Another thing to consider is whether we want the cache to have the
ability to look up the multiplexer in JMX, or whether that becomes the
task of some other integration layer (e.g. CacheJmxWrapper) that
updates
the Configuration and builds the cache. If we remove that from the
cache then:
a) JChannelFactory is only available from external injection --
i.e. the
cache doesn't add it to its own Configuration.
b) Not sure, but I think we don't need MBeanServer anymore.
+1 from me on this; I'm all for the simplicity.
That would leave only TransactionManager as the "neither fish nor
fowl"
type.
- Brian
6530
days inactive
6530
days old
jbosscache-dev@lists.jboss.org
1 comments
2 participants
participants (2)
-
Brian Stansberry -
Manik Surtani