Fix possible deadlock spanning DB transaction and caching lock with user references

[mtneug]

The JpaUserReferenceProvider#updateUserReference updates an in-memory cache as part of the DB transaction context. Putting something in the cache will acquire a lock on the cache. If the JpaUserReferenceProvider#loadUser method is called after the start of the DB transaction but before putting the object in the cache, the cache loader will try to read the user reference from the DB and put it into the cache if it cannot be found (e.g. after a Opencast startup). This also requires a lock from the cache but will block in the DB since the DB transaction is already running. Since this deadlock uses in-memory Java locks, it cannot be detected by the DB and the DB transaction will not be canceled.

This moves the cache update outside of the DB transaction context. When multiple user reference updates run at the same time there is still a race to insert into DB/cache. However, in practice the user reference is probably the same except for the last login date.

Two other commits are cleaning up JpaUserReferenceProvider a bit.

Your pull request should…

• have a concise title
• close an accompanying issue if one exists
• be against the correct branch
• include migration scripts and documentation, if appropriate
• pass automated tests
• have a clean commit history
• have proper commit messages (title and body) for all commits

[mtneug]

Additional info for the first commit: the last login date is updated by the login providers using JpaUserReferenceProvider. There is no need to set a new date again.

[gregorydlogan]

This seems reasonable to me. Not a huge fan of leaving the race in, could we switch the cache to some kind of concurrent map?

[mtneug]

This seems reasonable to me. Not a huge fan of leaving the race in, could we switch the cache to some kind of concurrent map?

The cache has an internal lock, so it should be threadsafe. The race I mention is between two calls of e.g. updateUserReference:

updateUserReference 1: tx finishes
updateUserReference 2: tx finishes
updateUserReference 2: cache update
updateUserReference 1: cache update (DB might have newer data)

But close calls to updateUserReference will likely not have updated user infos (apart from the last login date, maybe).