-
1. Re: Number of entries call on a JDBC store iterates over all entries in the database
ryanemerson Apr 10, 2017 5:27 AM (in response to wolframite)1 of 1 people found this helpfulWe don't utilise `SELECT COUNT(*)` in this context, as we calculate the number of entries in a cache by utilising the `Cache::keySet` method which utilises `AdvancedCacheLoader::process` to iterate over all entries in a store. As the `process` method allows a callback to be called for each entry in the store, it is not possible to just return a COUNT of rows.
-
2. Re: Number of entries call on a JDBC store iterates over all entries in the database
william.burns Apr 10, 2017 10:24 AM (in response to wolframite)1 of 1 people found this helpfulYou can do the select * by accessing the PersistenceManager directly.
cache.getAdvancedCache().getComponent(PersistenceManager.class).size();
This will call [1] underneath which does [2].
This won't work for all cases though, hence why this isn't done for Cache.size.
The biggest issue is when using passivation as we have to make sure there are no concurrent activation/passivation calls since we have to count both in memory and in the store separately but also prevent any overlap. So we can't only go to database.
Also any cache can put entries in the cache on a per call basis that can expire. These expired entries are removed on access or periodically. Therefore to get a correct size we have to go through each entry to test if the entry is expired or not and not count the ones that are. Since the stores are all interfaces the safest approach is to just count entries individually. This could be improved though if we change the select to something like the following:
select count(*) where expired > some-time
To be honest it just hasn't gotten as much attention as this was always something I wanted to improve on.
[1] infinispan/JdbcStringBasedStore.java at master · infinispan/infinispan · GitHub
[2] infinispan/AbstractTableManager.java at master · infinispan/infinispan · GitHub
-
3. Re: Number of entries call on a JDBC store iterates over all entries in the database
wolframite Apr 10, 2017 10:54 AM (in response to wolframite)@William
Thanks, that was exactly what I was looking for! In my case I'm using it together with an INVALIDATE mode cache, so it's ok to only count the database as it's the single source of thruth. It seems to obvious now that I see the solution!
-
4. Re: Number of entries call on a JDBC store iterates over all entries in the database
william.burns Apr 10, 2017 11:10 AM (in response to wolframite)Sounds great. The only issue as I mentioned is if you are using expiration, but it sounds like most likely aren't. So in this case as long as you have your cache as shared you should be good (if using a cluster).