This one time, at band camp, Thomas Braun said: TB>currently I need shared access mode because I have multiple open forms in TB>my application. Each form has its own transaction and I never know in which TB>form the user will decide to edit values and save them. The Database.lock() TB>method would get a timeout because the other transactions will not finish TB>until their forms are closed. The only solution I see at the moment is to TB>use one transaction for all forms. TB> TB>I don't understand why Castor assigns a read lock to any object loaded from TB>the database. I don't need this read lock, can I avoid it somehow?
Thomas, Is this a web application? If so, I've developed many of these using Castor and I've never had concurrency issues. In most of these web apps I also made use of long transactions (http://www.castor.org/long-transact.html). Use of long transactions is a *must* when developing web apps simply due to the nature of their use. Are you using long transactions or short transactions? The reason that Castor assigns a read lock is because it places the object(s) in the cache. This behavior is no different than just about every RDBMS. Upon reading any row in any table, the RDBMS creates a read lock for that row. Unfortunately there is no way around this currently. 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
