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
creative online development B.V.
t
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
jk bericht-
Van: Stefan Guggisberg [mailto:[EMAIL PROTECTED]
Verzonden: vr 14-9-2007 17:47
Aan: dev@jackrabbit.apache.org
Onderwerp: Re: Synchronized methods in ItemManager
hi martijn,
On 9/14/07, Martijn Hendriks <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> The ItemManager has a sma
Hi,
> where the second thread comes from
The application can use multiple threads.
Jackrabbit needs to protect itself from that.
Thomas
ilto:[EMAIL 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 ItemManag
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 applica
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 best-
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?
wel
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 both
14 matches
Mail list logo