[jboss-user] [JBoss Cache] Document updated/added: "JBoss Cache - Searchable Edition - Designs"

[Manik Surtani]

User development,

The document "JBoss Cache - Searchable Edition - Designs", was updated Feb 22, 2010
by Manik Surtani.

To view the document, visit:
http://community.jboss.org/docs/DOC-13454#cf

Document:
--------------------------------------------------------------
h1. JBoss Cache Searchable Edition (JBCS) Designs
 
h3. Historic
The current (v1.0) release of JBCS uses a listener approach.
 
1. The SearchableCacheFactory takes a running Cache, and creates a delegate
2. This delegate implements SearchableCache, which is a sub-interface of Cache
3. Most calls delegated to the underlying Cache, except the query related methods
4. A listener is created and attached to the cache
4.1. Used to listen for cache modifying events which originate both locally and remotely
4.2. Updates indexes based on events
 
h3. New
The plan is from v1.1 onwards, to drop the listener based approach as this can lead to complications with Hibernate Search (the interface to Lucene for indexing and searching).
 
Instead, we should create an interceptor and register this interceptor with the cache.
 
1. IndexingInterceptor should extend http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.0.3.GA/apidocs/org/jboss/cache/interceptors/base/CommandInterceptor.html.
2. Methods we are interested in overriding are any visitXXXCommand() that change the cache (such as CommandInterceptor.visitPutKeyValueCommand()).
3. On interception, we should first check if there is a transaction in progress (http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs/3.0.3.GA/apidocs/org/jboss/cache/InvocationContext.html.getTransaction() will tell you this)
4. If there is no transaction in progress, update indexes.
5. We should also override visitPrepareCommand() (and visitOptimisticPrepareCommand() as well, for backward compatibility).  Here, we should make a note of all modifications made to the cache
6. If this is a one-phase prepare command, update indexes immediately.  Otherwise, store the changes somewhere for now
7. We should also override visitCommitCommand().  Here, we should update indexes for all modifications stored in 6.
8. For visitRollbackCommand(), we should not do anything except free up resources by removing anything we store in 6 pertaining to this transaction.
 
That's it.  :-)
 
 
The IndexingInterceptor should be registered with the cache by using Cache.addInterceptor().  It would be a good idea to put this just before the CallInterceptor, which is the last interceptor in the chain.

--------------------------------------------------------------