title: Side effects of SessionFactory.Evict?
body: <p>Every so often I am tasked with making alterations to one or more business entities in our database that may already be cached in our internal application. To get the application to reflect these changes without cycling the app pool, I figured I'd embed the ability for dev/administrators to evict the cache from within the app's UI (either entirely or for certain objects), but I noticed the comments for the method state the following...</p>
  
  <pre><code>/// &lt;summary&gt;
  /// Evict an entry from the process-level cache.  This method occurs outside
  ///     of any transaction; it performs an immediate "hard" remove, so does not respect
  ///     any transaction isolation semantics of the usage strategy.  Use with care.
  /// &lt;/summary&gt;
  void ISessionFactory.Evict(Type persistentClass, object id);
  </code></pre>
  
  <p>What exactly does that mean? What could go wrong if I try to evict one or more objects that may be involved in a transaction, and is there anyway to avoid these side effects if they are destructive? I'm currently using SysCache2 and am looking for implementation details on how to use SqlDependency but I'm still curious about the Evict effects in the mean time.</p>
  
  <p><strong>UPDATE:</strong> Upon looking closer at the comments, it appears that <code>SessionFactory.Evict()</code> and <code>SessionFactory.EvictCollection()</code> remove from the process level cache, and <code>SessionFactory.EvictEntity()</code> remove from the second level cache. However the same disclaimer exists on either flavor. So my original question still stands. What dangers are there of evicting an entity from the cache (process or second level) if it's currently in use in another transaction?</p>