I am following on a bug report that I got, and I have confirmed that we have a thread safety issue within NHibernate.The conditions for that are quite esoteric, which is why no one got it so far. I attached a patch the expose the issue. This was introduced in r4679, to fix NH-1908.
The problem is that in ParameterTranslationImpl, we get the wrong value. There is a note there that says: // Steve Strong Note: The original Java does not do this decrement; it increments i for // every parameter type. However, within the Loader.GetParameterTypes() method, this introduces // nulls into the paramTypeList array, which in turn causes Loader.ConvertITypesToSqlTypes() to crash // with a null dereference. An alternative fix is to change the Loader to handle the null. I'm // not sure which fix is the most appropriate. // Legacy.FumTest.CompositeIDQuery() shows the bug if you remove the decrement below... That is indeed the error that I am getting most of the time, but that isn't what is bother me. What is bother me is that we have a test that fails only under multi threaded conditions. I tracked it down and it looks like the issue is with the query plan cache. It will serve the same instance of a query plan for several threads at the same time. That is fine on its own, the problem is that there are things there, like ParameterTranslationImpl, which are stateful, and get corrupted when used from multiple threads. I will commit a fix for this particular issue shortly, but it is something that we have to consider as well, because I don't think that we want to take the burden of ensuring that everything works right all the time under multi threading scenarios.
thread-safety-nh.patch
Description: Binary data
