UnitOfWorkImpl.rollback() doesn't properly unlock the Transactionable t. Doing some testing for another problem, t usually is a SourceNode. To get the lock to work under a SourceNode it must be checked out by the current user. However, rollback() unlocks anything that was locked, no matter who checked it out. The patch protects the unlock by isCheckedOutByUser and unlocks it before checking it in, which seems to be the proper order.
Created attachment 19710 [details] Checks to make sure user has checked file out before unlocking
Actually this shouldn't be necessary, since all transactionable objects should be local to the UnitOfWorkObject, i.e. they are created by the current user.
Would it be possible to create a test case for this bug?
I see it's changed. It used to be that any page that was visited was added to the list. Which is why it is checking to make sure it is checked out by the current user. It would appear that the issue has been cleared up. Although the patch might make it clear as to what is going on and help guard against any future issues. I'll leave it up to you to decide.
I don't really dare to touch the repo layer now, let's schedule that for 1.4.1.
+1