The iparsys is located at a higher level than all children which inherit the content of the iparsys. Therefor on any change of the iparsys (which affects and children) all children are invalidated by default dispatcher invalidation ruleset. So by default you don't need to pay special attention to dispatcher caching if you want to use the iparsys.
If you want don't want to invalidate pages, which are below that page with the iparsys, but do not contain an iparsys themselves (and therefor do not change upon change of the ancestor's iparsys), that is very hard. At least with an reasonable effort. Because you would need to implement 2 additional features:
* on invalidation tell the dispatcher exactly which pages to invalidate; the dispatcher does not know and does not care about iparsys and such, it just knows files. On the other hand you need to extend the invalidation logic on AEM to evaluate each child page if it contains an iparsys. Doable, but it takes a lot of work!.
* On the other hand you need a special invalidation handler on dispatcher side, which just invalidates the pages which should be invalidated (as instructed by AEM via the invalidation request). Also there's the limit that you invalidate only per-directory. That means that when you invalidate a single file in a directory, all other files in the same directory are invalidated as well.
I would say, that this is a lot of effort for a very low improvement of the cache hit ratio. Of course your usecase can be so special that this improvement of caching outweighs the cost of implementing it. But for all usecases I am aware of this time could be spent somewhere else much better (e.g. by optimizing rendering time).
regards,
Jörg
