Re: Synchronized methods in ItemManager
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 heavily synchronized. I understand the need to keep caches in sync etc, but it seems that we could be more performant (and I know I still owe the group numbers for performance :-) if we could use another pattern such as reader/writer locks, etc. to ensure consistency but allow for multiple simultaneous reads and writes. -paddy
Re: Synchronized methods in ItemManager
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? well, maybe 'official' is the wrong term. whenever these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. I see. Note that you now said "is probably safe" :-) yeah, I looked up the relevant messages in the archive and found that we only say 'probably' ;) Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. FWIW, we should make up our minds what we want to agree, and clearly document that. I don't care a lot about what we say, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. well, the main reason behind my call for a thread-safe implementation is for clients that use a session from multiple sessions *by mistake* and not on purpose. the repository should not break in any case. regards marcel
Re: Synchronized methods in ItemManager
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-effort basis... the fail-fast behavior of iterators should be used only to detect bugs..." That way we don't have to synchronize, but also reduce the risk of corrupted internal structures on concurrent access within the same session. Thomas
Re: Synchronized methods in ItemManager
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 the wrong term. whenever these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. I see. Note that you now said "is probably safe" :-) Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. FWIW, we should make up our minds what we want to agree, and clearly document that. I don't care a lot about what we say, but I'm not convinced that guaranteeing more than JSR-170 says would be good for interoperability of clients. Best regards, Julian
Re: Synchronized methods in ItemManager
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 these kind of questions arise on the mailing list, we tell people that reading from multiple thread is probably safe, while writing is not. searching the mail archive should give you some of those statements. Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... I agree, we should definitively do that. Again, I think jcr2spi should be entirely thread safe for any kind of operation, while the SPI level is IMO debatable, because it is at a lower level. regards marcel
RE: Synchronized methods in ItemManager
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
Re: Synchronized methods in ItemManager
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 in general doesn't. So an application taking advantage of that may break on different JCR implementations. Finally, how does that translate to JCR2SPI and the SPI interfaces? It seems we need to clarify the thread-safety of spi.RepositoryService and spi.SessionInfo... ... Best regards, Julian
Re: Synchronized methods in ItemManager
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 application should not access the same session within multiple threads. But if the application does, synchronization is required within Jackrabbit to avoid corruption. Where synchronize on the session is required, this should be done on a high level to improve performance. Regards, Thomas
Re: Synchronized methods in ItemManager
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 ItemManager instance of a Sesssion can also be accessed by other threads than the one that is using the Session that created that ItemManager. I am just wondering when that could happen. 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 addition there's also the scenario where one thread saves changes on session and those changes get propagated to other sessions that are accessed by other threads. as for multiple threads on a single session instance I personally prefer a more coarse grained synchronization to avoid monitor contention. see: JCR-890. regards marcel
RE: Synchronized methods in ItemManager
Hi, 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 ItemManager instance of a Sesssion can also be accessed by other threads than the one that is using the Session that created that ItemManager. I am just wondering when that could happen. The reason I am asking this is because we have the feeling that the synchronization overhead begins to count on a multiprocessor (8 CPUs) platform. Best regards, Martijn -- Martijn Hendriks creative online development B.V. t: 024 - 3888 261 f: 024 - 3888 621 e: [EMAIL PROTECTED] Wijchenseweg 111 6538 SW Nijmegen http://www.gx.nl/ > -Original Message- > From: Thomas Mueller [mailto:[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 >
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
RE: Synchronized methods in ItemManager
Hi Stefan, Thanks for your reply, but I still don't understand. Without synchronization, cache entries can only be overwritten when multiple threads have concurrent access, isn't it? It is not clear to me where the second thread comes from. Best wishes, Martijn -Oorspronkelijk 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 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 ItemManager maintains a cache of NodeImpl/PropertyImpl instances. #getItem(itemId) e.g. is synchronized in order to guarantee the cache integrity. the following code fragment needs to be synchronized, otherwise cache entries might get accidentally overwritten: // check cache ItemImpl item = retrieveItem(id); if (item == null) { // create instance of item item = createItemInstance(id); } cheers stefan > > Best wishes, > > Martijn > > > -- > > Martijn Hendriks > creative online development B.V. > > t: 024 - 3888 261 > f: 024 - 3888 621 > e: [EMAIL PROTECTED] > > Wijchenseweg 111 > 6538 SW Nijmegen > http://www.gx.nl/ >
Re: Synchronized methods in ItemManager
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 ItemManager maintains a cache of NodeImpl/PropertyImpl instances. #getItem(itemId) e.g. is synchronized in order to guarantee the cache integrity. the following code fragment needs to be synchronized, otherwise cache entries might get accidentally overwritten: // check cache ItemImpl item = retrieveItem(id); if (item == null) { // create instance of item item = createItemInstance(id); } cheers stefan > > Best wishes, > > Martijn > > > -- > > Martijn Hendriks > creative online development B.V. > > t: 024 - 3888 261 > f: 024 - 3888 621 > e: [EMAIL PROTECTED] > > Wijchenseweg 111 > 6538 SW Nijmegen > http://www.gx.nl/ >
Synchronized methods in ItemManager
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: 024 - 3888 261 f: 024 - 3888 621 e: [EMAIL PROTECTED] Wijchenseweg 111 6538 SW Nijmegen http://www.gx.nl/