Lihua, unfortunately, the information provided by you is not enough for us to even diagnose the exact problem you are experiencing. Can you please provide us with a small test case that demonstrates the problem you are encountering ? As pointed out already below, a small code fragment would be ideal for starters.
Regards Werner PS Please do not sned HTML messages to this mailing list. --Original Message Text--- From: Lihua Cao Date: Tue, 2 Mar 2004 13:26:18 -0700 Hi, Werner, My problems happen when exceptions occurs and database.rollback() itself get something wrong, all write-locks to objects loaded in that transaction are not released. Any writing action to those objects will throw write timeout exceptions. Hope this can give you some clue about where the problem is in castor. Thanks for your help. Lihua -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Sunday, February 29, 2004 5:04 AM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Question about LockNotGrantedException Lihua, can you please provide us with some code fragments, the relevant portion of your mapping file and a stack trace (if possible), so that we can analyse the problem you are seeing. In general, the release notes of the RC1 and RC2 candidates suggest that a patch for bug 1462 has been included. This patch fixes a problem with type conversion between java.sql.Timestamp and java.sql.Date. As a result, this will 'fix' a lot of (incorrectly reported) ObjectModifiedExceptions for mappings where java.sql.Timestamp has been used as field type when defining the field mapping. Unfortunately, this fix (whilst correct per se) only works with RDBMS that do not truncate fraction values of a time value. Iow, with mySQL (which does not store any milliseconds at all), this will still cause the same (incorrect) exceptions to appear. Have a look at bug 1533 at http://bugzilla.exolab.org/show_bug.cgi?id=1533 This shows you that the problem has been identified at least, but no solution has been provided until now ... 8-(. For the curious and open minded ones, we have been discussing a possible solutions introducing an database-centric exception mechanism .. donations welcome, of course ... ;-). In addition, afair, there is another bug report that identifies a problem with not releasing locks in a very special load scenario. I cannot find this bug report right now, but top of my head, the problem only occurs when an object cannot be loaded as it does not exist. It will be released later on, though ... but for details please try to find the bug report. Regards Werner This patch --Original Message Text--- From: Lihua Cao Date: Fri, 27 Feb 2004 17:48:50 -0700 Hi, I got almost exactly same problem. My case is that one of my method load an User object to update, but it fails, rollback() is called. But seems that the lock is not released. Any action to update that object will fail. Choose different object to work with, there is no problem. So I am wondering whether this problem has been fixed. I am using the latest version of castor 0.9.5.2 Thanks. Your help is really appreciated. Lihua Re: [castor-dev] Question about LockNotGrantedException � From: Keir Bowden � Subject: Re: [castor-dev] Question � about LockNotGrantedException � Date: Mon, 17 Feb 2003 02:00:06 -0800 Hi, We experienced a similar problem over the last few weeks. Last Tuesday, after copious debugging, we found the cause of it, at least in our case. We are using exclusive locking with no caching, so it fairly easy for us to reproduce. We use the following style of object mappings, that result in multiple objects being retrieved in a single access: -- snip -- <class name="user.jdo.CastorUser" identity="id"> <map-to table="us_user" /> <field name="id" type="long" > <sql name="user_uid" type="bigint"/> </field> <field name="username" type="string"> <sql name="usu_username" type="varchar" /> </field> <field name="password" type="string"> <sql name="usu_password" type="varchar" /> </field> <field name="parent" type="user.jdo.CastorGroup"> <sql name="parent_uid" /> </field> -- snip -- so in the snippet above, when loading a user, their parent group is loaded also. Our problem was arising when a deadlock exception occurred while retreiving the parent of a user, which was happening automatically thanks to the above object mapping. A locknotgrantedexception was thrown, and the transaction was backed out, but the user object remained locked until we restarted the server. It turns out that as the exception was thrown when attempting to pull the parent in "automatically", the locknotgrantedexception was propagated back to the attempt to load the user, due to the nesting of the function calls. However, the user object had been successfully locked - it was the underlying parent that failed. Unfortunately there is nothing in the code to detect that it is a nested call that failed, and so the user object is not unlocked. Next time we attempt to do anything as this user, locknotgrantedexceptions all over the place! I've worked around this for the time being by modifying the load() method in org.exolab.castor.persist.TransactionContext.java to attempt to release the lock when a lock not granted exception is caught : -- snip -- }catch ( LockNotGrantedException except ) { // | it is an important one...... // ---- KAB NEW --- try { // KAB - release the lock, as we may be a nested field that was loaded and locked // - correctly. ObjectEntry tmpEntry = getObjectEntry( object ); tmpEntry.engine.releaseLock( this, tmpEntry.oid ); } catch (Exception e) { //looks like we didn't have the lock. No matter //System.out.println("Didn't have lock anyway."); } // ---- END OF KAB NEW --- -- snip -- Thus far it's done the trick. Caveat emptor and all that, and if you are not using exclusive locking you probably need to handle this in other methods - fetch() seems likely. I've tested this with lock timeouts set to 10 seconds also, which causes most of our concurrent transactions to fail, and it has recovered every time. Hope this helps. Ken Burcham wrote: -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
