[jbosscache-dev] Re: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Bill Middleton wrote:
A cursory (and likely naive) inspection of DefaultCacheFactory and
CacheImpl seems to indicate that providing my own channel should be
fairly easy to implement, even if an extension won't quite get the job
done, since channel is private. The intimidating part is the binding
between the "official" multiplexed channel (mbean) and other
functionality which implies a full app-server, such as the
TransactionManager.
Not sure what you mean here by "binding". Passing a JChannelFactoryMBean
to the RuntimeConfig doesn't carry with it a requirement to pass in a
TransactionManager. Think of RuntimeConfig as basically being a
placeholder through which the external environment can pass in complex
objects the cache may need and through which callers can get access to a
few of the cache internals.
If I were to pass in a channel to CacheImpl,
whether multiplexed or not, I don't think I'll mess with
setUsingMultiplexer() and friends in the Configuration. Since I'm going
to manage the muliplexer functionality myself I guess it makes sense to
let Cache think that it's just a simple channel. This seems safe
enough, I hope.
Sure, as long as in reality it's a multiplexed channel, so the cache
doesn't get messages it won't understand. If you're writing your own
extensions, then presumably you know how the code will be used and can
guard against misuse. So, the barrier for what's considered "safe" can
be a lot lower. :)
Thanks very much for the reply. Those of us who haven't made the
"big
switch" to a full jboss deployment are very glad to be able to use your
products individually in a "mix and match" configuration. :-)
+100; that's why I'm not happy with RuntimeConfig using
JChannelFactoryMBean as its property type; it implies more than is
necessary. We also need to better document the purpose of the
RuntimeConfig (and maybe conceptually tighten it up a bit.)
- Brian
On 4/6/07, *Brian Stansberry* <brian.stansberry(a)redhat.com
<mailto:brian.stansberry@redhat.com>> wrote:
Hmm. The cache's RuntimeConfig object only allowing injection of
JChannelFactoryMBean isn't good; at least being able to inject a plain
org.jgroups.JChannelFactory seems called for. The ugly bit is the class
and the interface have no direct type relationship, so you'd have to
expose properties of both types.
I think the reason for not allowing passing a Channel to the
RuntimeConfig is that would imply exposing the Channel as well. The
Channel is not meant to be exposed to outside callers for the same
reason we no longer expose the RpcDispatcher.
Bill Middleton wrote:
>
> > It does appear that I can get access to the rpcdispatcher
for the
> > jboss cache using getRPCManager(), or via implementing the
> depracated
> > RpcTreeCache, so it may be that my implementation can just
use an
> > standard CacheSPI, and doesn't need to extend CacheImpl
(or some
> other
> > concrete class), right?
>
> I would discourage you from doing that. Exposing the
RpcDispatcher in
> JBossCache was necessary for our internal aspects to invoke
the (public)
> methods on it, but we never intended for users of cache to
use it. So,
> in 2.0 we removed them (or made them available only through
the SPI
> API).
>
>
> Thanks for the advice, Bela. Unfortunately, an mbean is not a viable
> option for us. I can gladly create a multiplexer using the standard
> jgroups api (as seen in MultiplexerStressTest.java, for example), but
> that'd imply an ability to pass in my Channel directly to the Cache
> constructor, I assume, and DefaultCacheFactory doesn't seem to
> interested in letting me do that.
>
> Bill
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com