Optimistic Locking progress report 3 - good news and bad news

From: Mike Kienenberger (mkienen..laska.net)
Date: Thu Feb 05 2004 - 18:18:21 EST

  • Next message: Andrus Adamchik: "Suggested license statement upgrade"

    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

    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
        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.


    This archive was generated by hypermail 2.0.0 : Thu Feb 05 2004 - 18:18:27 EST