Alex 20 Dec 2011: Over the last releases we gained experience with this type of cache. Already in 4.0 we introduced other means that offered bigger performance improvements, especially the asynchronously loading of action drop downs. With 4.1 we gained performance by combine multiple SELECTs and reducing the number of overall DB queries. It turned out that the RBAC cache brings usability issues with it, since users experience time lacks before repository objects become accessible, e.g. after permission changes, precondition changes, ...
 
I think we should consider to abandon the rbac cache and to more optimize existing DB queries and reduce their overall number. The benchmark feature in 4.1 has been greatly improved to get the data necessary to do this on productive systems.

JF 6 Feb 2012: We try to get some information about the real-life performance gains of this feature from productive installations.

Kiegel 08 May 2012: I propose to make this feature optional, e.g. installations with performance issues could activate it and installations with those usability issues could deactivate it.

JF 11 June 2012: @Colin ??? This is already an optional feature. The problem is that users are not aware that this feature is activated on their installation and which side-effects come with it. Moreover it does not necessarily improve performance.
 
We ask anyone who uses this cache to share his/her experience here.