All, Nick, Thanks for your explanation. We are using 0.9.5.3 .
I will do a rollback on all the transactions when a PersistenceException is thrown. I am really interested to know if anyone is using castor in a high volume , mission critical application and the problems they faced if any and how solved it. Thanks Vijay -----Original Message----- From: Nick Stuart [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 26, 2005 4:32 PM To: [email protected] Subject: Re: [castor-user] Transaction locks and muti threaded access Will try my best to explain some of these issues in line. On 4/26/05, Vijayanand Sukumar <[EMAIL PROTECTED]> wrote: > > We have been using castor-struts for about 2 years now and we are > having some issues related to the castor. we are at a stage where due > to performance issues we are thinking of moving away from castor. > > Any explanations/solutions for the given problems will be greatly > appreciated. > > 1. When more than 1 thread access the same object, is multiple copies > of the same object is created or is the same instance of the object is > used across multiple > transactions. > If it the same object then wouldn't it affect performance as in > our case we have about a hundred users using the same record. Yes its the same object. But no you shouldn't see a performance hit because its serving it out of the Cache. In fact, if the object is used enough, and is always in the cache you would see a performance gain. This assumes most of your actions are read only, as several threads acting on the same object and trying to do changes will cause problems. > > 2. when a transaction fails , the locks on all the objects related to > that transaction are not released. > we have had instances where a > LockNotGrantedException: WriteTimeOut > occurs on a JDO object and the lock on the object is not released > until the server is re-started. > How can I release a lock on that object ? > > This problem kills all the mission critical applications where the > application cannot be restarted. Can this be overcome if an explicit > rollback is called ? If you have a PersistenceExcpetion during a transaction (between db.begin and db.commit) you should always do a rollback. This will release the objects and locks. If you dont do this my best guess as to what could happen to your data is as good as yours. > 3. when a commit fails and rollback is not explicitly called are all > locks on the objects in that transaction released ? They should be yes. If they are not my guess is that its a bug. You never mentioned what version of castor you are using. > > 4. A lock is obtained on an object even if it stated in the mapping as > read-only. This slows down all the queries even if they are read-only > , how can I overcome this ? > Not sure about this one myself....never ran into any problems with it. > Based on my experience so far, I have a feeling that castor is not > suited for high-volume, mission critical applications. > All my apps are well used, but not considered high volume so my experince in that area is limited. Although I'm pretty sure other people on the list will share their experinces about this. > Has anyone used castor in a high-volume, mission critical application > and have success story? > > > ANY HELP WOULD BE GREATLY APPRECIATED. > > Thanks > > Vijay > Hope this helps some. Anyone else want to throw something this way? -Nick
