Description
Content bootstrap can interfere with the lock timeout. See attached stacktrace.
What happens is that the Jackrabbit LockManager implementation unlocks timed out locks on a separate thread while using the same underlying session that is currently being used for bootstrapping, i.e. it contains a concurrent session access bug. So when the lock is timed out and the bootstrap process is still in progress we get concurrent modification exceptions due to this concurrent session access. Until this is resolved in Jackrabbit we are better off avoiding the lock time-out mechanism together with a write-intensive process such as bootstrapping.
Attachments
Issue Links
- causes
-
REPO-1236 InitializationProcessor lock has no timeout
- Closed