Affects Version/s: None
Fix Version/s: 5.0.1
Processed by team:Pulsar
The ConfigurationServiceImpl, the AutoExportServiceImpl and related helpers like AutoExportConfig and EventJournalProcessor, use and must use several independent JCR sessions as some of their processing needs to run on separate threads.
Furthermore JCR Session state changes (e.g. pending changes) needs to be kept separate/isolated between these threads and processes.
In the current implementation however there are a few incorrect usages of the same JCR session(s) between these processes.
This normally won't or shouldn't cause a problem as the process execution between these processes is mostly serialized.
But under constrained situations like long 'transactions' within one process, or failures which keep 'stale data' (pending changes) in a JCR session, this actually easily breaks down.
Implementing the proper and needed separation of JCR sessions itself isn't difficult, but it requires 2 important changes in the process(es) handling:
- Previously saving (updating) the processed autoexport lastRevision property in the EventJournalProcessor was done using the same session to update the HCM baseline.
Thereby both those changes became a single 'atomic' save.
But now reading/saving the autoexport lastRevision, and all the handling JCR handling in EventJournalProcessor, needs to use its own dedicated JCR session, separate from the session used by the ConfigurationServiceImpl to load/update the HCM baseline.
As a consequence, updating both now no longer is or can be a single 'atomic' operation, which theoretically introduces a risk of only one succeeding. In practice however this won't really be a problem, and not even one if it would really occur (a re-play of those 'missed' journal events will be harmless and typically produce an empty 'diff').
- Not so much a result of the separation of JCR session but of recognizing the needed coordination between processes is that the AutoExportService needs to ensure that the EventJournalProcessor initializes the event journal, and the starting event revision to start with, right away during startup.
Because the EventJournalProcessor runs in a background thread, there is a chance that when the AutoExportService has been created and processing proceeds in the ConfigurationServiceImpl while the EventJournalProcessor thread has not yet initialized.
In which case some new changes on the main (ConfigurationServiceImpl) thread might get 'lost' for AutoExport, until the EventJournalProcessor has been initialized.