It looks like a timeout in the lock that's guarding the data in the default cache implementation, which suggests a slow operation or deadlock.
The default timeout is 10 seconds. The purge interval is also 10 seconds. So each 10 seconds the timer elapses and will call the purge function. This will then try to lock the data and clear it. It will wait for the lock for 10 seconds and if that passes, it will throw a locktimeout exception, as you're seeing.
The cached data is simply a dictionary, and we're locking that both for storing and purging the data.
So if you cache a resultset, the same procedure is taken: it will take the same lock on the same data, then store the data, and then give back the lock.
What I can think of is this:
- you fetch a lot of data and want to cache the resultset. This operation takes > 10 seconds or at least longer than the purgeInterval specified when creating the resultsetCache (default is 10seconds). This store operation grabs the lock to store the data
- the purge timer elapses, and as the lock is taken, it has to wait
- it waits for 10 seconds. If the lock isn't returned before that, you'll get the exception you're seeing.
So if the caching operation of the large resultset takes > 10 seconds and the purge timer elapses e.g. right after that operation starts, you get this exception I think, because the caching of the resultset (which has the lock) takes longer than the purge timer will wait for its turn on the lock, so it will timeout. The stacktrace shows that.
One workaround could be to look at what large resultset is there to be cached. That they start to see it now is likely because they perhaps imported or generated a lot of data for a resultset you're caching somewhere. To increase the purgeInterval to e.g. 1 minute, change the value you pass to the ResultsetCache constructor (if you're not passing anything, it's 10 seconds). purgeInterval is in seconds.