Manik Surtani wrote:
This is an attribute in the <locking /> configuration element and is used to define the number of lock stripes used by the LockManager, *if* striped locking is used.
Now I wonder whether we need a tuning parameter of this sort in the data container as well. Consider that the SimpleDataContainer is backed by a CHM and the FIFO and LRU variants are backed by something very similar to a CHM (in that there are lockable segments which contain hash tables). In both cases, I use default concurrency levels (16 segments), but maybe this should be configurable too? Should this be a separate attribute, or could "concurrencyLevel" be reused here?
The way I see it, LockManager needs a higher number of stripes since transactions could span keys that are in > 1 stripe. Segments, however, are only locked for the duration of a write access to the container which is a) typically very short and b) usually limited to the number of active threads, which is related to the number of cores/CPUs.
Basically, what I am saying is that the latter could probably be guessed/hard coded rather than made configurable, and even if made configurable, is unlikely to be the same as the number of stripes used by the LockManager.
Thoughts/comments?
I'm just thinking that if we would provide such an config param, it would be hard for the users to grasp it. TBH, even the concurrency level its not very easy to explain, but saying something like "increase it if you see lots of timeouts" should help.
Can't we determine it based on the LockManager's concurrency level?