[jbosscache-dev] Re: [javagroups-users] Considering migrating to jboss cache from DistributedTree

[Brian Stansberry]

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 at redhat.com 
> <mailto:brian.stansberry at 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 at redhat.com <mailto:brian.stansberry at redhat.com>
> 
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com