The good news is that I think I have optimistic locking working for both
individual and batch updates.
Not only that, but it's locking specified per entity and per objectAttribute
using "lock-type=optimistic" and "lock=true".
The downside is that oracle (and, while not openbase, maybe others) requires
that qualifiers be written as "where attribute is null" instead of "where
attribute = null". This means the sql generated in the where clause has to
be rewritten based on each data value. That means it can't work in batch
mode, if I understand correctly, since the sql string has to be a constant.
SQL> select * from user_table where user_id = 56 and activation_code = NULL;
returns 0 rows.
SQL> select * from user_table where user_id = 56 and activation_code is NULL
;
returns 1 row.
SQL> select * from user_table where user_id is 56 and activation_code is
NULL ;
generates an error.
Am I misinterpreting something? Is optimistic locking based on
null-capable fields incompatible with batch updates and prepared statements
in general? To me they appear incompatible, at least for Oracle. For
OpenBase and other databases that allow value = null qualifiers, it's
workable.
The only solution I can think of is to always use
runBatchUpdateAsIndividualQueries() when updating an entity with optimistic
locking enabled, and recreate the sql string with each query. This also
gets around the problem with int[] executeUpdate() and getUpdateCount(),
although I think I have that problem solved (I've tested it with a single
batched update statement with no null-valued attribute fields under Oracle,
and it appeared to work.)
A second issue is the new ObjEntity and ObjAttribute method naming.
I used int getLockType() and void setLockType(int) to represent locking
types.
final public static int LOCK_TYPE_NONE = 0;
final public static int LOCK_TYPE_OPTIMISTIC = 1;
I don't think anyone will have a problem with that.
I used boolean getLock() and void setLock(boolean) for ObjAttribute.
To me, even though these methods match the xml, they don't represent well
the idea of "use as optimistic locking field." Should I change the names
of these methods, and to what?
As soon as I hear back on these issues, I'll post yet another update of the
code with the changes to CAY-52.
-Mike
This archive was generated by hypermail 2.0.0 : Thu Feb 05 2004 - 18:18:27 EST