Deadlock due to combination of synchronized on methods and repository.
Thread A tries to update metadata for entry X in context Z.
Thread B tres to remove entry Y in context Z.
1) Thread A locks the repository (MetadataImpl.setGraph row 110)
2) Thread B locks context Z (method ContextImpl.remove row 842)
3) Thread B tries to lock the repository but have to wait for thread A (method ContextImpl.remove row 846)
4) Thread A tries to lock context Z but has to wait for thread B (method ContextImpl.getEntryByURI row 704)
See attached file with a tread dump of the problem. In this dump the thread A ends with 9152 and thread B ends with 9195.
Note: Step 4 is due to that an update of a metadatagraph demands an update to inverse-relational-cache on other entries that must load these entries first, hence the call to getEntryByURI.
Suggested solution, remove synchronized on the method level and replace with synchronized on the cache or something else that does not cause these kind of conflicts.
Solved deadlock problem by removing unneccessary synchronized on entry remove and used the softcache as mutex object instead of the context for loading entries.