Details
-
Bug
-
Resolution: Fixed
-
Critical
-
2.0 M3
-
None
-
Integration
-
Unknown
-
N/A
-
N/A
-
Description
If a listener to a document (or other document produce events like object/class/attachment, etc.) get the document from XWiki#getDocument instead of manipulating the one given with the event, it has a chance of being called before the one which invalidate the document from the cache and use the wrong (old) one.
The main workaround is to use as much as possible the document passed with the event instead of asking it to the store again, but it's not always possible when you don't control the API of some library which reload the document from the XWiki#getDocument.
To be extra safe, you can call XWikiCacheStore#onEvent with the same parameters as the ones given to your listener:
@Inject
@Named("cache")
private Provider<XWikiStoreInterface> documentCache;
@Inject
private RemoteObservationManagerContext remoteContext;
private void forceResetDocumentCache(Event event, Object source, Object data)
{
XWikiContext xcontext = this.xcontextProvider.get();
if (xcontext != null) {
XWikiStoreInterface store = xcontext.getWiki().getStore();
if (store instanceof XWikiCacheStore) {
((XWikiCacheStore) store).onEvent(event, source, data);
}
}
}
@Override
public void onEvent(Event event, Object source, Object data)
{
// Workaround https://jira.xwiki.org/browse/XWIKI-20564
// Make sure the document in the cache is the right one in case of remote events
if (this.remoteContext.isRemoteState()) {
forceResetDocumentCache(event, source, data);
}
[...]
}
The ideal fix for this would be to add support for listeners priority and give a very high priority to XWikiCacheStore listener.
Attachments
Issue Links
- is caused by
-
XWIKI-4182 Make event use a lazy loading XWikiDocument when converted back to local event
-
- Closed
-