This one time, at band camp, Keir Bowden said:
KB>I am having a problem with concurrent Castor transactions from different
KB>machines accessing the same database.
KB>
KB>I am using access="db-locked", as I have two jboss servers accessing the same
KB>datbase via Castor. However, I am still seeing the following error when both
KB>servers attempt to update the same object in the database :
KB>
KB>--- snip ---
KB>
KB>org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted:
KB>Object of type com.ilumin.dcx.entity.jdo.Message with identity
KB>57,000 has been modified by a concurrent transaction
KB>
KB>--- snip ---
KB>
KB>It then goes on to say that the cached object does not match that in the
KB>database, even though I have also set <cache-type cache="none"/> in my mappings
KB>file.
KB>
KB>After some further digging, it appears that this problem is occurring because I
KB>am retrieving the message objects from the database using Database.load(). The
KB>javadocs say that this method will take into account the type of locking being
KB>used, but this doesn't appear to be the case. If I change this to run an OQL
KB>query that selects from the database on object id, I get the behaviour that I
KB>expect. I've turned on full debugging and have noticed that the SQL for loading
KB>message objects doesn't have the "HOLDLOCK" hint that I would expect, but the
KB>OQL query generated select statement does.
KB>
KB>I am using the latest Castor - 0.9.4.2 - has anyone else experienced this? Is
KB>this a known problem with Database.load().
Keir,
This is not an issue with the Database.load() method. This method checks
the cache first for the object being queried. If it exists, it is loaded
from there. If it does not exist in the cache, then Castor goes to the
database to load the data from there and materialize the objects. If you
want to load from the database, using an OQL query is the correct avenue.
As for the HOLDLOCK syntax, I may be wrong, but I believe that this syntax
comes from SQL Server is not SQL standard. So, 1) if objects are being
loaded from the cache, obviously there will be no locking at that point,
and 2) when querying using OQL and not passing the Database.ReadOnly
argument to the execute() method, the FOR UPDATE syntax is used to lock
the row(s).
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
