[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-595) Merge API interfaces

Manik Surtani (JIRA) jira-events at jboss.com
Wed Nov 8 10:29:41 EST 2006


    [ http://jira.jboss.com/jira/browse/JBCACHE-595?page=comments#action_12346512 ] 
            
Manik Surtani commented on JBCACHE-595:
---------------------------------------

Cool.  One other small thing:  for completeness the MapModifications
struct should probably also have a "public Map unmodifiedEntries" field.

Manik Surtani wrote:
Ok, sounds cool, will add this to the JIRA task.

How about a variation on Ben's idea of providing an enum to specify
the type of change?  Sample API follows.

/**
 * Called before and after a {@link Node} is modified. Data passed
in the 
 * <code>modData</code> param can be used to determine what was
modified. 
 * <p/>
 * When called with <code>pre == true</code>, <code>modData</code>
is the 
 * initial state of the {@link Node} before modification.
 * <p/>
 * When called with <code>pre == false</code>, the contents of
<code>modData</code> 
 * depend on the value of <code>modTtype</code>:
 * <ul>
 * <li><b>PUT_KEY_VALUE</b>: Map contains the single key/value pair
that was added.</li> 
 * <li><b>REMOVE_KEY_VALUE</b>: Map contains the single key/value
pair that was removed.</li> 
 * <li><b>PUT_MAP</b>: Map contains the new state of the {@link
Node} following modification. 
 * This map includes modified key/value pairs as well as any that
were not affected.</li> 
 * </ul>
 * <p/>
 * Implementations interested in seeing the difference in the node
data in the PUT_MAP case 
 * can cache the <code>modData</code> map passed when <code>pre ==
true</code>, and then 
 * when the <code>pre == false</code> callback is received, pass the
cached map and the new 
 * <code>modData</code> to {@link
org.jboss.cache.util.Util.diffNodeData(Map pre, Map post)}.  *
 * @param fqn     Fqn of the node being modified
 * @param pre     <code>true</code> if the modification is about to
be applied, 
 *                <code>false</code> if it has already been applied
 * @param isLocal <code>true</code> if the modification originated
locally, 
 *                <code>false</code> if it was replicated from
another node 
 * @param modType PUT_KEY_VALUE, REMOVE_KEY_VALUE or PUT_MAP
 * @param modData Unmodifiable {@link Map}; will not be
<code>null</code>. See 
 *                description above.
 */
public void nodeModified(Fqn fqn, boolean pre, boolean isLocal,
ModificationType modType, Map modData);

public class Util {

  public static MapModifications diffNodeData(Map pre, Map post) {  
  // do the diff here }

  public static class MapModifications {
     public Map addedEntries;
     public Map removedEntries;
     public Map modifiedEntries;
  }
}


Advantage here is JBC goes to little effort to support this, so
overhead is low if the listener isn't interested. CacheListener impls
that are interested in modifications, but where the app never calls
put(Fqn, Map)
also have very little overhead.  I believe Jerry's DistributedState
is such a case.  The big overhead of doing the diff is only incurred
by CacheListener impls that care, and we provide much of the code to
do it for them. 


> Merge API interfaces
> --------------------
>
>                 Key: JBCACHE-595
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-595
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.3.0.SP1
>            Reporter: Manik Surtani
>         Assigned To: Manik Surtani
>            Priority: Blocker
>             Fix For: 2.0.0.GA
>
>          Time Spent: 30 minutes
>  Remaining Estimate: 0 minutes
>
> * Merge TreeCacheListener, EnhancedTreeCacheListener, add an API to pass in data
> * Merge CacheLoader + ExtendedCacheLoader

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list