|Re: Hung threads [message #1706421 is a reply to message #1706212]
|Wed, 26 August 2015 18:51
| Chris Delahunt
Registered: July 2009
Similar issues can occur all the time, but it is not necessarily a bug or a true deadlock. If one thread is building an object, any other threads must wait until that thread is done. Depending on your model, there are any number of reasons this might cause a bottleneck, such as if you have a large model constantly being refreshed as just one example. True database deadlocks also cause issues, but generally with writes, not reads.
In the thread dump provided by Pawel, the issue still is not obvious as it does not show the thread that holds the lock, only the ones backing up waiting for it. The first set of 12 threads are building an entity1 instance and trying to build one of the references that is eagerly fetched - presumably entity2 instances. A quick solution would be to make this relationship lazy and these 12 threads would be able to skip having to wait for the lock, but it does not show an actual deadlock situation. This is why the session.getIdentityMapAccessor().printIdentityMapLocks() I suggested earlier is important, as it will show the threads that hold each lock, allowing you to correlate what each thread in the dump is doing to the locks it holds. From there, you can identify which thread is causing the deadlock (or bottleneck) and decide what should be done to prevent it.
Powered by FUDForum
. Page generated in 0.03836 seconds