While debugging an issue in our custom authenticator that creates and updates user accounts during logins, I found something that appears to be a bug in how DefaultHibernateUser objects are being handled (and cached?) in confluence.
It looks like the DefaultHibernateUser objects are being cached with its (groups) collections attached with the hibernate session that performed an operation on the object recently (in a different thread). When another thread with a new hibernate session attempts to update such a user instance the exception below is thrown. We are not passing the objects between threads via http session or in any other way. Each thread obtains an instance of the user class via userAccessor.
Steps to reproduce:
You need two threads that get the user instance via an instance of UserAccessor, and call UserAccessor#saveUser(confUser).
- thread 1 opens a hibernate session
- thread 2 opens a hibernate session
- thread 1 fetches a user
- thread 1 saves the user
- thread 2 fetches the same user as thread #1
- thread 2 saves the user
- the exception is thrown in thread 2
- thread 1 closes the hibernate session - this is important, it seems that if the session was closed before thread 2 called saveUser, everything would be ok
- thread 2 closes the hibernate session