10 Aug
2016
10 Aug
'16
10:14 a.m.
Hi Thomas
Thanks for responding and thanks for supporting the suggested solution.
I understand the doc.Key-issue that you mentioned. Yet, I think this is not
a
XWikiCacheStore#loadXWikDoc concern. In my understanding the expected
document
to load is defined by the document-reference and the language. Thus the
Hibernate-Store must be concerned in setting the context database according
to the Wiki-Reference before loading the document. This is acctually already
done in the XWiki#getDocument call. I agree that this might be the wrong
place to do it.
Thus, I would suggest to fix this issue in the XWikiHibernateStore on a
seperate jira-issue.
Maybe this could be combined with a significant performance improvment in
loading
the documents with fewer sql-queries per loading action.
With XWIKI-13623 I try to tackle the issue about randomly loosing BaseObject
data because of an not thread safe construction and publication of
XWikiDocument
java objects in XWikiCacheStore. Because this issue gave us a big headache
in
production multiple times, I solved it in our project in the way mentioned.
If the xwiki-dev team supports the suggested solution, I would be willing
to proceed
and prepare a pull request for an adapted XWikiCacheStore fix.
Kind regards,
Fabian
2016-08-08 12:07 GMT+02:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
XWikiCacheStore#loadXWikiDoc is actually a bit tricker
than that right
now for retro compatibility and laziness (really need to rewrite this
whole store API) reasons and before applying what you propose the way
it deals with document uid should be modified a bit.
Hibernate store is always loading the document from the wiki indicated
in the context completely ignoring the wiki in the XWikiDocument
object. That means that doc.getKey() may be different than the key of
the document that will actually come from the hibernate store. So
before adding DocumentLoader jingling a first thing to do is generate
the initial cache key with a mix of the wiki id located in the context
and the XWikiDocument reference.
Then what you propose sounds good.
On Mon, Aug 8, 2016 at 8:53 AM, Fabian Pichler
<fabian.pichler(a)synventis.com> wrote:
Hi devs
http://jira.xwiki.org/browse/XWIKI-13623
I would like to discuss the suggested solution, before I start
implementing
it:
*I suggest the following solution:*
Introducing a nested DocumentLoader class which loads the document
calling
the basestore loadXWikiDoc in a synchronized
getDocOrLoad method. The
DocumentLoader objects gets instantiated in the cacheStore on a cache
miss.
It then gets stored in a ConcurrentHashMap using
the same key which is
used
for the document cache (DocumentReference
including language). Using
putIfAbsent to insert the DocumentLoader and calling the synchronized
load
method on the object in the map solves the memory
visibility issue and
moreover ensures that the same XWikiDocument is not loaded multiple times
concurrently from the database. It is still possible to load different
documents in parallel. A DocumentLoader will load the XWikiDocument only
once and the returns the identical document object on any following call
of
the synchronized getDocOrLoad method.
WDYT?
Kind Regards,
Fabian
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs