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:
