Kalpesh Patel wrote:
Bruce,
Thats fine that we will change the Cache implementation but if you see my mail was not regarding the Cache performance.
My real Question is that if accessmode is "read-only" in mapping.xml then why we are doing this locking business after fectching the object from cache.
Its OK to do this locking business in accessmode="shared" or "exclusive" as we will either upgrade or waitforconfirmation or maintain a linkedlist of readonly locks. But does it makes sense to maintain this linkedlist of readonly locks if we know in advance that we are just going to do read operations?
The real problem is that code becomes serial, if all I was doing was fetching the same object in different Transactions, in multiple threads.
Kalpesh,
My apologies for not answering your question. The only comment I can make on this at the moment is that the call to typeInfo.acquire() takes place because it can return any type of lock including a read-only lock. I'm not saying that this is correct, all I'm saying is that it is done this way because of legacy code. I agree with your assessment that this should not be taking place at all. However, there doesn't seem to be a simple solution to this issue because it's so intertwined with the rest of the code base.
Could you please file a bug of type enhancement here in Bugzilla:
http://bugzilla.exolab.org/
Please provide all the info you've included above and any additional suggestions or even a patch. If you're so inclined as to include a patch, please be aware of the Guidelines For Code Contribution available here:
http://www.castor.org/cvs.html#Guidelines-For-Code-Contribution
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\\"F9E<G)E=\\$\\!F<FEI+F-O;0\\`\\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://incubator.apache.org/projects/geronimo.html
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
