Bruce Snyder wrote:
Keir,I've dug around in the Castor code to try to find out why the SQL generated to load my objects doesn't have any locking in it, and I found that the
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.
protected StringBuffer getStandardStatement( boolean lock, boolean oj )
method of JDBCQueryExpression.java doesn't do anything based on the lock parameter. There is a comment at the end that :
--- snip ---
// There is no standard way to lock selected tables.
--- snip ---
It seems to me that my access="db-locked" parameter is quietly discarded at this point, which fits with the behaviour that I am seeing.
You are correct on the HOLDLOCK syntax - it is SQL Server (and Sybase, I believe). It does appear in the OQL query debug, but not in the SQL query that is (I assume) cached for the loading of objects.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).
Cheers
--
Keir Bowden
Olive Systems Limited
http://www.olive.co.uk
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
