[prev in list] [next in list] [prev in thread] [next in thread]
List: jboss-user
Subject: [JBoss-user] RE: [JBoss-dev] [ANN] Cache-invalidation commited
From: "marc fleury" <marc.fleury () jboss ! org>
Date: 2002-09-30 18:28:48
[Download RAW message or body]
Sacha,
great work, please put this in documentation as I mentioned before.
documentation-getting-started.text and/or documentation-advanced.text
(or word).
Then we will collect these and make a compilation.
marc f
> -----Original Message-----
> From: jboss-development-admin@lists.sourceforge.net
> [mailto:jboss-development-admin@lists.sourceforge.net] On
> Behalf Of Sacha Labourey
> Sent: Monday, September 30, 2002 10:35 AM
> To: Jboss-Dev; jBoss-User Mailing List
> Subject: [JBoss-dev] [ANN] Cache-invalidation commited
>
>
> Hello,
>
> I've just commited a generic cache-invalidation mechansim to
> HEAD (mainly in org.jboss.cache.invalidation). Some of the
> code and ideas comes from Bill Burke's implementation of the
> Seppuku algorithm that has been recently commited.
>
> It allows to have any cache to be invalidated by any
> resource. In addition, Plugins allows to have
> distributed-cache-invalidations (cluster for example).
> Invalidations can come from an external process or be send to
> an external process (or both).
>
> Full integration of this generic service with JBoss entity
> beans has been implemented as well.
>
> Design
> ======
> Each JVM has an *InvalidationManager* (IM) (it could have
> more). Each IM will manage invalidation-events and
> subscriptions from two kinds of actors:
> - Local caches and invalidators
> - Plugins
>
> InvalidationGroup
> =================
> Caches that share invalidations messages (i.e. that represent
> the same data), share a common *InvalidationGroup* (IG). Examples:
> 1) if you deploy your bean twice: once for RW access in
> commit option C and once for RO access in commit option A
> with other optimisations, both EJB represent the same
> underlying data => they live in the same InvalidationGroup
> 2) An EJB that is deployed on two nodes of a cluster live in the same
> InvalidationGroup: a modification made on a bean on node 1
> must be invalidated from the cache of the same EJB on node 2.
>
> The IM is able to invalidate one key, a set of keys or a set
> of keys for a set of InvalidationGroups in a single shot,
> thus minimizing network cost (when using a bridge) and
> allowing to group all invalidations happening in a single
> transaction and involving more thant one cache so that they
> are propagated in a single shot.
>
> When a new IG is created, it is represented as an (dynamic)
> MBean => it is accessible through JMX for invalidation or any
> other action (statistics could be added for example)
>
> Local Caches
> ============
> A cache, will get access to the local InvalidationManager and
> will subscribe using an appropriate InvalidationGroup (i.e.
> shared identifier, name). Whenever an invalidation message is
> received by the IM for this IG, the cache will receive a
> callback. Caches and related object must implement the
> *Invalidable* interface.
>
> EJB: An extension of the EntityInstanceCache has been
> implemented that hook up in the cache-invalidation mechanism:
> InvalidableEntityInstanceCache. Configuration information is
> explained below.
>
> Invalidator
> ===========
> Invalidators (i.e. an interceptor for example) subscribe to
> the local IM and can send invalidation messages (single key,
> set of keys or set of keys for a set of groups). Each
> invalidation is sent to the subscribed Invalidable objects
> AND to the registered plugins (more info below)
>
> EJB: An invalidator for EB has been implemented as an
> interceptor in EntityBeanCacheBatchInvalidatorInterceptor in
> the package org.jboss.cache.invalidation.triggers. It will
> not only send invalidation messages, but will also group them
> so that they are only broadcast at transaction-commit-time.
> For this, it uses the
> org.jboss.cache.invalidation.InvalidationsTxGrouper helper class.
>
> Bridges
> =======
> Bridges are IM plugins are not linked to a specific IG but,
> instead, receive all invalidations and are able to send
> invalidations messages for any IG. They generally bridge
> several IM running on distant nodes, but other usage can be
> imagined such as providing a protocol-friendly gateway to an
> IM for a client running in a Javaless environnement (DB
> trigger that would only do HTTP invocations for example).
>
> When an invocation is sent through a bridge for a given IG,
> it is sent to every Invalidable object registered to this IG
> AND to all other bridges linked to this IM (except the
> source-bridge of course)
>
> Two bridge implementations have been implemented:
> JavaGroups-based (in the cluster module) and JMS-based.
>
> Note that several instances of a given bridge can be started
> at the same time on the same node and linked to any present IM.
>
> JMS-Bridge
> ==========
> This simple bridge sends and receives invalidations messages
> through a given JMS Topic. All invalidations messages are
> send to this JMS topic, without filtering the content. The
> bridge can be configured to ONLY send invalidations
> messsages, ONLY receive invalidations messages or BOTH: this
> is interesting for application that want to communicate with
> the IM through JMS but are not interested in receiving the
> invalidations that comes from this this IM. (bridge not
> really tested yet.)
>
> JavaGroups-Bridge
> =================
> This bridge sends and receives invalidations messages through
> JavaGroups. NOT all invalidation messages are sent: each
> bridge will dynamically discover other bridges running in the
> cluster (with the same bridge name) and ask them for the list
> of IG that they have locally. Thus, the bridge will only
> forward invalidation messages targetting IG that exist on
> remote nodes. This information is dynamically recomputed when
> the cluster-topology changes or when new IG are
> created/dropped on nodes of the cluster. Furthermore,
> invalidations can be forwarded synchronously or
> asynchronously, depending on the invalider choice. Tested.
>
> Configuration
> =============
> By default:
> - the "default" config starts an InvalidationManager (and
> contain the config for a JMS-bridge in comments)
> - the "all" config starts an InvalidationManager and the JG-Bridge
>
> EJB:
> ====
> To use the cache invalidation mechanism with your EB, you
> first need to use the appropriate config. One has been
> created in standardjboss.xml: "Standard CMP 2.x EntityBean
> with cache invalidation". Thus, you first need to modify your
> jboss.xml file to use this configuration. (See "PROPOSAL"
> below for more info)
>
> Then, for each EB, you need to activate the registration to
> the local IM by using the appropriate "cache-invalidation" tag:
>
> <jboss>
> <enterprise-beans>
> <entity>
> <ejb-name>SimpleEJB</ejb-name>
> <configuration-name>Standard CMP 2.x EntityBean with
> cache invalidation</configuration-name>
> *** <cache-invalidation>True</cache-invalidation>
> </entity>
> </enterprise-beans>
> </jboss>
>
> Note: if set to True, the interceptor will forward
> invalidations, no matter what is the current commit option of
> the container. Note 2: if set to true, the cache will only
> subscribe for invalidation messages if the container runs in
> CO A or D.
>
> At this point, the container will itself decide what is the
> name of the InvalidationGroup by taking the EJB name and will
> use the default InvalidationManager instance. If what you are
> trying to achieve is cluster-wise invalidation of cache, then
> that is fine because the EJB name will be the same on all
> nodes, and consequently all EJBs will share the same IG. But
> if what you want to achieve is to have two identical EJBs
> running in the same JBoss instance that invalidate their
> respective cache, they will not belong to the same IG because
> each EJB will have its own name. Thus, you need in this case
> to assign the same IG name to both EJBs:
> <jboss>
> <enterprise-beans>
> <entity>
> <ejb-name>SimpleEJB</ejb-name>
> <configuration-name>Standard CMP 2.x EntityBean with
> cache invalidation</configuration-name>
> <cache-invalidation>True</cache-invalidation>
> *** <cache-invalidation-config>
> ***
> <invalidation-group-name>MY_IG_FOR_SIMPLE_EJB</invalidation-gr
> oup-name>
> *** </cache-invalidation-config>
> </entity>
> <entity>
> <ejb-name>SimpleEJB-Replica</ejb-name>
> <local-jndi-name>cmp2/simple/Simple</local-jndi-name>
> *** <cache-invalidation-config>
> ***
> <invalidation-group-name>MY_IG_FOR_SIMPLE_EJB</invalidation-gr
> oup-name>
> *** </cache-invalidation-config>
> <cache-invalidation>True</cache-invalidation>
> </entity>
> </enterprise-beans>
> </jboss>
>
> Thus, by default, only setting the cache-invalidation tag to
> true is enough (and starting at least a bridge) to get
> distributed-cache-invalidations!
>
>
> PROPOSAL:
> =========
> Currently, only one EB container configuration has been
> written in standardjboss.xml (CMP 2.0 non-clustered). To
> satisfy all scenarios, we would have to duplicate all EB
> container config: cmp 1.1, CMP 2.0, bmp, clustered-xxx, etc..
> This makes an administration nightmare. Do you mind if I had
> the new interceptor + cache to all the existing EB container config?
> Consequences:
> - if the cache-invalidation is set to False, the interceptor
> is a no-op interceptor and the new code in the invalidable
> cache is never used (not even registered in the IM)
> - the code of the cache is not new: it only extends the
> currently-used cache (if you fear new bugs)
> - if no InvalidationManager is started and
> <cache-invalidation> is set to False (or not set at all, as
> False is the default), the EB container will start without
> any problem/exception: thus the current behaviour is kept and
> there is no need to start an additional InvalidationManager
> if you don't need it.
>
> Cheers,
>
>
>
> Sacha
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Jboss-development mailing list Jboss-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic