Re: Optimistic locking on delete: appendOptimisticLockingAttributes calls getRetainedSnapshot() but may be null for simple deleteObject()

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Feb 22 2005 - 21:04:00 EST

  • Next message: Andrus Adamchik: "Wiki linking to Jira issues"

    > That sounds good to me, but I have no idea how it's done :)
    >
    > I've added this to the issue along with flattened relationships. I'm
    > not
    > sure what further progress I will make on either issue.

    I can look at the NPE piece. Just assign CAY-276 to me if you don't
    find a quick solution.

    As for the flattened relationships, I don't think we should attempt to
    handle them. In general any relationship that doesn't have *all* of its
    joins rooted in the FKs of the table being updated is unsuitable for
    optimistic locking. I can't think of any exceptions from this
    definition (maybe updates/deletes with subselect??)

    Andrus

    On Feb 22, 2005, at 10:27 AM, Mike Kienenberger wrote:
    >> On Feb 16, 2005, at 10:08 PM, Mike Kienenberger wrote:
    >>> It looks like the solution is to use getCachedSnapshot() instead
    >>> (which
    >>> first returns getRetainedSnapshot() if available).
    >>> Does this make sense?
    >
    > Andrus Adamchik <andru..bjectstyle.org> wrote:
    >> On the one hand it does. On the other hand what if there is no cached
    >> snapshot either (e.g. some snapshots are invalidated manually or
    >> removed when a shared cache reaches its size limit)? One solution I
    >> see
    >> is to retain snapshots of deleted objects (just like we do for the
    >> modified ones) if optimistic locking is involved.
    >
    > That sounds good to me, but I have no idea how it's done :)
    >
    > I've added this to the issue along with flattened relationships. I'm
    > not
    > sure what further progress I will make on either issue.
    >
    > -Mike
    >

    This archive was generated by hypermail 2.0.0 : Tue Feb 22 2005 - 21:04:06 EST