Hi,
Sorry for missing the original post on the Oak list.
Like Carsten said, sessions do not support multiple threads. See also
https://docs.adobe.com/docs/en/spec/jcr/2.0/4_Connecting.html
The warning you receive is from a protection mechanism in Oak that
prevents the worst. I.e. data corruption. However, there are no
guarantees beyond that. E.g. performance or even progress (no deadlocks).
Michael
On 28.03.19 07:32, Carsten Ziegeler wrote:
Hi,
a resource resolver is single threaded and must not be used concurrently
by multiple threads. Main driver (but not the only one) is the JCR
session which requires this.
However, there is nothing in the Sling code base blocking you from doing
so anyways. So we don't have any additional checks like Oak/Jackrabbit
has. Therefore the log message you see, is initiated by Oak. I don't
want to sent you from one list to another, but to my knowledge your
latest code looks ok to me and I'm not aware that you can only have one
thread for a service user. But maybe your getServiceResourceResolver
method is always returning the same instance and not creating one per
call? If not, I fear this is an issue for Oak.
Regards
Carsten
Roy Teeuwen wrote
Hey sling users,
This is a repost from the userlist of oak because I didn't get a reply
there, so I hope I might get one here:
We have a system that migrates our sites based on migration rules, the
psuedocode is as the following:
resourceResolver = getServiceResourceResolver("migration-user");
for(Site site in sites) {
migrateSite(resourceResolver)
}
Everything works fine, but we would like it more performant, so the
change I did was the following:
resourceResolver = getServiceResourceResolver("migration-user");
for(Site site in sites) {
threadPool.submit(new Runnable() { run() {
migrateSite(resourceResolver)
});
}
This gave the following exception:
21.03.2019 11:32:47.244 *WARN*
[sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-4]
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate Attempted to
perform hasProperty while thread
sling-threadpool-fb6dc0ad-6c32-47c1-9779-e8acba0ef747-(migration-service)-2
was concurrently writing to this session. Blocked until the other
thread finished using this session. Please review your code to avoid
concurrent use of a session.
So I decided to change the code to the following:
for(Site site in sites) {
threadPool.submit(new Runnable() { run() {
resourceResolver = getServiceResourceResolver("migration-user");
migrateSite(resourceResolver)
});
}
But it seems that the warn that is being thrown is still being thrown,
does this mean that getting a new service resourceresolver based on
the same user name still get into lockings / synchronizing issues? Is
there any way to solve this?
Thanks,
Roy
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
