Hey guys, Thanks for the replies.
In the getServiceResourceResolver I do actually call resourceResolverFactory.getServiceResourceResolver, making it a new resource resolver instance for every thread. so in my knowledge this does create a new session, but it's on the same user name? Greets, Roy > On 28 Mar 2019, at 08:52, Michael Dürig <mdue...@apache.org> wrote: > > > 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 >> cziege...@apache.org
