PROTECTED]
Sent: Friday, September 14, 2007 6:12 PM
To: dev@jackrabbit.apache.org
Subject: Re: Synchronized methods in ItemManager
Hi,
where the second thread comes from
The application can use multiple threads.
Jackrabbit needs to protect itself from that.
Thomas
I should have explained my question in more detail. The Javadoc of the
ItemManager states that there's one ItemManager per Session: it is
created in the constructor of SessionImpl. Sessions are not thread-safe
by specification. Because some methods in the ItemManager are
synchronized, an
Hi,
we have the feeling that the synchronization overhead begins to count on a
multiprocessor (8 CPUs) platform.
Do you have some test case where this can be verified?
on a single session instance I personally prefer a more
coarse grained synchronization
I agree. In my view, an
Marcel Reutegger wrote:
our official statement still is you may use multiple threads on a
session that just read but a single thread on a session that writes. in
- Could you please provide a pointer to that statement?
- Also, we need to keep in mind that even if Jackrabbit allows that, JCR
Hi,
we have the feeling that the synchronization overhead
begins to count on a multiprocessor (8 CPUs) platform.
Do you have some test case where this can be verified?
No, not yet but we're working on it. As soon as we have some results
I'll get back on this.
Best wishes,
Martijn
Julian Reschke wrote:
Marcel Reutegger wrote:
our official statement still is you may use multiple threads on a
session that just read but a single thread on a session that writes. in
- Could you please provide a pointer to that statement?
well, maybe 'official' is the wrong term. whenever
Marcel Reutegger wrote:
Julian Reschke wrote:
Marcel Reutegger wrote:
our official statement still is you may use multiple threads on a
session that just read but a single thread on a session that writes. in
- Could you please provide a pointer to that statement?
well, maybe 'official' is
Hi,
but I'm not convinced that guaranteeing more than JSR-170
says would be good for interoperability of clients.
Maybe trying to detect concurrent access and throwing an exception
would be an option? From HashMap javadocs: Fail-fast iterators throw
ConcurrentModificationException on a
Julian Reschke wrote:
Marcel Reutegger wrote:
Julian Reschke wrote:
Marcel Reutegger wrote:
our official statement still is you may use multiple threads on a
session that just read but a single thread on a session that writes. in
- Could you please provide a pointer to that statement?
Reading this post and going through some of the work I have done re.
syncronization in the persistence manager I wonder if the real issue is
not threads sharing a session, which it is clear they shouldn't, but
that each session is tied to a persistence manager and an item manager
which are
Hi all,
The ItemManager has a small number of synchronized methods such as
getItem(ItemId id), which is heavily used. I cannot figure out why these
calls must be synchronized...can somebody give me an idea? Thanks!
Best wishes,
Martijn
--
Martijn Hendriks
GX creative online development B.V.
hi martijn,
On 9/14/07, Martijn Hendriks [EMAIL PROTECTED] wrote:
Hi all,
The ItemManager has a small number of synchronized methods such as
getItem(ItemId id), which is heavily used. I cannot figure out why these
calls must be synchronized...can somebody give me an idea? Thanks!
the
Hi,
where the second thread comes from
The application can use multiple threads.
Jackrabbit needs to protect itself from that.
Thomas
13 matches
Mail list logo
