During the upgrade to JDK11 (
DS-4380), I encountered some odd behaviors (while updating tests) with how the "org.dspace.core.Context" class behaves immediately after a "commit()" occurs.
After some deeper digging in the Context & HibernateDBConnection code, I realized that the "Context.commit()" method was temporarily invalidating the Context object (i.e. "context.isValid()" would return false immediately after a commit()...even though the Context object was still usable).
I also noticed that the Context.commit() method had no tests to prove that it behaved as expected. I was immediately able to prove the unexpected behavior via a new test. Namely, on "master", a test of this nature will cause a failure:
- First, make changes to an object within a valid Context.
- Call "context.commit()"
- Immediately call "context.isValid()". You'd expect it to return "true" (as a commit() should not invalidate a Context). However, it will return false.
- Make other changes on that same Context (without calling a commit())
- Call "context.isValid()" again. This time, it will return "true" (as making more changes in the Context will create a new Hibernate Transaction, thus making the previously-invalid Context "valid" again)
Based on the description of the "Context.commit()" method, this behavior seems inappropriate. It also implies a failure of the "Context.isValid()" method to actually return whether a Context is "valid" and can continue to be used. Even though it immediately returns "false" the Context can continue to be used nonetheless.
I've prepared a PR to refactor/correct the behavior of these Context methods based on new Tests (both for "org.dspace.core.Context" and "org.dspace.core.HibernateDBConnection"). I'll post that PR shortly.