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.