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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] 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 [EMAIL PROTECTED] > 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
