Hello all,
I've been profiling our application today looking for contention between threads and such and noticed that our last remaining bastion of thread contention seemed to be nextFuncName. nextFuncName uses StringHelpers.randomString, which eventually uses a SecureRandom instance. To deal with thread safety issues, this SecureRandom instance's access is wrapped in a synchronized block.
From what I could find out there (e.g.,
http://stackoverflow.com/questions/1461568/is-securerandom-thread-safe ), SecureRandom is already thread safe. That said, it is thread safe by using locks as well, so I doubt it would attend to our problem of threads locked waiting for other threads generating func names. The aforementioned Stack Overflow thread mentions ThreadLocalRandom to deal with thread lock contention issues, but that's Java 7 only, so that doesn't seem like something that could roll into Lift proper. Could we do our own thing in Lift whereby we would use a thread-local SecureRandom instance in StringHelpers instead of a global one, thus avoiding lock contention on this rather frequently used corner of the framework?
Thanks,
Antonio