Re: Concurrent Write issues with Jackrabbit
Sure.. But with 100 concurrent threads I guess we should not be looking for big hardware anyways. Also if we cluster the repository I guess still we deal with a global lock across nodes.. So not sure how much we gain Thanks Shashank On Wed, Jul 28, 2010 at 9:06 PM, Thomas Müller wrote: > Hi, > >> What I am getting here is that writes will be >> serialized due to a Single Write lock > > For scalability, you also need scalable hardware. Just using multiple > threads will not improve performance if all the data is then stored on > the same disk. > > Regards, > Thomas >
Re: Concurrent Write issues with Jackrabbit
Hi, > What I am getting here is that writes will be > serialized due to a Single Write lock For scalability, you also need scalable hardware. Just using multiple threads will not improve performance if all the data is then stored on the same disk. Regards, Thomas
Re: Concurrent Write issues with Jackrabbit
Sure.. We are already going through them. I just wanted to make sure if we have some kind of configuration to allow parallel writes in jackrabbit if we write to different parts of repository..What I am getting here is that writes will be serialized due to a Single Write lock Thanks a lot Shashank On Wed, Jul 28, 2010 at 8:37 PM, Thomas Müller wrote: > Hi, > > Do you use Day CRX / CQ? If yes, I suggest to use the Day support. > > Regards, > Thomas >
Re: Concurrent Write issues with Jackrabbit
Hi, Do you use Day CRX / CQ? If yes, I suggest to use the Day support. Regards, Thomas
Re: Concurrent Write issues with Jackrabbit
Hi, The problem is performance . Thats based on concurrent writes we are doing. So if I see the design of jackrabbit and as much I make out of it is that the Write lock is acquired at the SharedItemStateManager level which is above PersistanceManager. We tried changing to DB persistance manager but that didnt scale as well and we continued to see almost same results as with File Persistance Manager We see a write through put of about 3.5 secs to 7 secs for workflow creation through Day workflow using the REST API's. This is when we run 100 concurrent users. I think it should be few millisecs per creation Thanks Shashank On Wed, Jul 28, 2010 at 8:11 PM, Thomas Müller wrote: > Hi, > > Are you sure the problem is "concurrency" and not "performance"? Are > you sure that the persistence manager you use does support higher > write throughput? What persistence manager do you use, and what is the > write throughput you see, and what do you need? > > Regards, > Thomas >
Re: Concurrent Write issues with Jackrabbit
Hi, Are you sure the problem is "concurrency" and not "performance"? Are you sure that the persistence manager you use does support higher write throughput? What persistence manager do you use, and what is the write throughput you see, and what do you need? Regards, Thomas
Re: Concurrent Write issues with Jackrabbit
Thanks Marcel, We cannot batch it in a single session as it will lead to thread safety issues.. Each request is handled in a different session . We might lead to corruption of repository by sharing session Thanks Shashank -- View this message in context: http://jackrabbit.510166.n4.nabble.com/Concurrent-Write-issues-with-Jackrabbit-tp2304674p2305071.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: Concurrent Write issues with Jackrabbit
hi, jackrabbit currently indeed serializes writes on the persistence level. as a workaround you could batch multiple writes into a single session save. though, I'm not sure if that's an option in your case. regards marcel On Wed, Jul 28, 2010 at 11:25, smjain wrote: > > Hi All, > We see a serious Write lock contention issue when we are trying to write to > jackrabbit through different jcr sessions. > > We see huge number of threads waiting on a write lock when a session.save is > done. > > All threads are writing to a different part of the repository but it seems > as per the SharedItemStateManager > > design we have just one Write Lock for the entire workspace. > > We tried with FineGrained Locks but that doesnt help either as it just > optimizes read and still we have a single Write lock. > > Thoughts/Suggestions > > Regards > Shashank > -- > View this message in context: > http://jackrabbit.510166.n4.nabble.com/Concurrent-Write-issues-with-Jackrabbit-tp2304674p2304674.html > Sent from the Jackrabbit - Dev mailing list archive at Nabble.com. >
