As per this document, when dealing with multiple threads we'd have to create one session for each thread:
https://cqdump.wordpress.com/2013/11/25/cq-development-anti-pattern-single-session-multiple-threads/
Does this still apply with the latest JackRabbit Oak used in 6.3 and above?
Solved! Go to Solution.
Views
Replies
Total Likes
Yes, this still applies.
Views
Replies
Total Likes
Views
Replies
Total Likes
Thanks. There's still nothing about shared sessions there.
Found this link:
https://cqdump.wordpress.com/2015/03/02/aem-scaling-patterns-avoid-shared-sessions/
And as pointed out there, it does give the exception related to concurrent use of a session when I try to use the same session with multiple threads.
In that case, it's supposed to serialize the thread access but weirdly the time taken with shared sessions and with separate sessions and multiple threads are very similar. Hmm...
@Jörg_Hoh : Any thoughts?
Views
Replies
Total Likes
Yes, that's still true.
Views
Replies
Total Likes
Views
Replies
Total Likes
Views
Replies
Total Likes
Yes, this still applies.
Views
Replies
Total Likes
@Jörg_Hoh : Is this rule also applicable to session object which is just being used to read. I think we can reuse session object between multiple threads if we are sure that at no point in time we are calling session.save and session object is just being used to read data from jcr/
Views
Replies
Total Likes
I normally object to this approach, because the session object is not thread-safe. And even if this normally not a problem with just reading (as you barely corrupt on-disk data) there is no guarantee that you won't get inconsistencies in in-memory data-structures.
I know that it works in at least some cases, but that does not mean that under heavy concurrency there might be inconsistencies, as not everywhere thread-safe datastructures are used.
My recommendation is still 1 session = 1 thread. Also much easier to set as a guideline.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies