[jboss-cvs] JBossCache/src/org/jboss/cache ...

[Manik Surtani]

  User: msurtani
  Date: 07/06/14 11:19:23

  Modified:    src/org/jboss/cache   CacheImpl.java CacheListener.java
  Log:
  JBCACHE-1107 and JBCACHE-1109
  
  Revision  Changes    Path
  1.89      +1 -0      JBossCache/src/org/jboss/cache/CacheImpl.java
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: CacheImpl.java
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/CacheImpl.java,v
  retrieving revision 1.88
  retrieving revision 1.89
  diff -u -b -r1.88 -r1.89
  --- CacheImpl.java	11 Jun 2007 21:17:20 -0000	1.88
  +++ CacheImpl.java	14 Jun 2007 15:19:23 -0000	1.89
  @@ -864,6 +864,7 @@
         cacheStatus = CacheStatus.DESTROYING;
   
         regionManager = null;
  +      notifier.stop();
         notifier = null;
   
         // The rest of these should have already been taken care of in stop,
  
  
  
  1.11      +4 -7      JBossCache/src/org/jboss/cache/CacheListener.java
  
  (In the diff below, changes in quantity of whitespace are not shown.)
  
  Index: CacheListener.java
  ===================================================================
  RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/CacheListener.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -b -r1.10 -r1.11
  --- CacheListener.java	30 May 2007 11:35:15 -0000	1.10
  +++ CacheListener.java	14 Jun 2007 15:19:23 -0000	1.11
  @@ -16,14 +16,11 @@
    * The {@link org.jboss.cache.AbstractCacheListener} provides a class with no-op implementations for all the methods defined in the
    * interface, as a convenience if you are not interested in listening for all available events.
    * <p/>
  - * It is important to note that notifications happen in the same process thread as the call to the cache.  This means that if your
  - * listener implementation blocks or performs a long-running task, the original caller which triggered the cache event may block until
  - * the listener callback completes.  It is therefore a good idea to use the listener to be notified of an event but to perform any
  - * long running tasks in a separate thread so as not to block the original caller.
  - * <p/>
  - * In addition, any locks acquired for the operation being performed will still be held for the callback.  This needs to be kep in mind
  - * as locks may be held longer than necessary or intended to.  See above paragraph on long-running tasks that should be run in a
  - * separate thread.
  + * It is important to note that notifications happen in a separate thread as the one that triggered the event.
  + * <p/>
  + * Any locks acquired for the operation that triggered the event will not be valid for the callback.  This needs to be kept in mind
  + * as any calls into the cache made from a listener will be treated as a new call, completely unrelated to the call that
  + * triggered the event.
    * <p/>
    * Also important to note is that all data maps passed in to the listener methods are read-only defensive copies of the actual data
    * stored in the cache.  Therefore it is safe to assume that the collections are static snapshots.  If changes to the cache data are