Hi Gaetan, You are correct that queryCount() does not currently use the Entity Engine cache.
There are three main reasons for this: - Missing Cache Architecture: EntityCache currently only stores single GenericValue objects or List<GenericValue> result sets. It doesn't have a structure for caching scalar numbers (like counts) mapped to conditions. - High Invalidation Overhead: A "count cache" would need to be invalidated every time any record matching that condition is created, updated, or removed. For busy tables, this overhead could easily outweigh the benefits. - Database Optimization: Relational databases are already highly optimized for SELECT COUNT(*) queries. Application-level caching for counts often provides negligible speedup compared to the native database execution. If you have a very specific, read-heavy use case where the database count is a bottleneck, the best approach is to manually wrap your queryCount() call with a custom UtilCache in your specific service logic, giving you complete control over its lifecycle. Hope this helps! Kind Regards, --- Arun Patidar On Fri, Feb 27, 2026 at 1:32 PM gaetan.chaboussie < [email protected]> wrote: > Hi community, > > We came accross a use case with a queryCount() call that would greatly > benefit from cache. > > But it seems that the queryCount() method doesn't use cache ever [1] > > Would it be a good idea to allow the use of cache in queryCount() ? > > I can't really see a side effect yet and i didn't find any historical > reason for this behaviour. > > > Best regards, Gaetan > > [1] > > https://github.com/apache/ofbiz-framework/blob/5bb12e6693f1e51b6ea6f85f618f000d9d3000fd/framework/entity/src/main/java/org/apache/ofbiz/entity/util/EntityQuery.java#L454 > >
