> Since behind the scenes you are executing various different queries using multiple > threads, and they might be touching/using shared resources lower down.
Good point, and most probably you are right. > which is to fix up QueryImpl, not to do aggressive locking (at least in > the isUnique method), and I > think it will at least remove the current blocking issue. So far, Slice has imposed almost no demand on existing kernel -- which is battle hardened code. So naturally, I am apprehensive of change in threading logic in kernel.QueryImpl. Any change of this nature *must* validate itself against a set of multithreaded tests (with or without Slice). -- View this message in context: http://n2.nabble.com/slices-hangs-if-run-with-Multithreaded%3Dtrue-tp1645757p1650047.html Sent from the OpenJPA Developers mailing list archive at Nabble.com.
