Re: Lazily column retrieval

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Sun Aug 28 2005 - 16:48:25 EDT

  • Next message: Gentry, Michael \(Contractor\): "RE: Lazily column retrieval"

    On Aug 27, 2005, at 3:41 PM, Gili wrote:

    > Could you possibly help me add pessimistic locking support to
    > Cayenne? I've got a use-case that requires it.
    >
    > I'm hoping to add both pessimistic locking and streaming BLOBs
    > to the next release but I am new to Cayenne so I don't know where
    > exactly to start.

    Hi Gili,

    You've already found ExtendedType API. This is a place to start doing
    streaming BLOBs.

    I am not a big fun of pessimistic locking (possibility of deadlocks,
    lowered overall throughput and inefficient resource use...) and as a
    result don't have much experience with it. So I haven't given it much
    thought and won't be able to provide a good advice without doing some
    research, including cross-db issues.

    However I am all for including this feature for completeness. It can
    definitely be useful. So if you start on the implementation, I'd
    suggest you to subscribe to cayenne-devel and post your questions
    there. Time permitting, myself and, I am sure, others would be able
    to help with integration.

    One piece of it is already in place - attributes and relationships
    can be tagged as a part of a lock. This is currently used for
    optimistic locking and can be extended to pessimistic locking (though
    AFAIK not all db allow column-level locking ... this will have to be
    abstracted through DbAdapter SQLActions).

    Not sure about the flow, i.e. how the lock is created... Probably
    some method at the DataContext level (DataContext.lock()) that would
    result in all select queries to be executed with "FOR UPDATE" clause
    until the next commit or rollback.

    Also if I understand correctly, JDBC Connection that created a lock
    must be the one to unlock it (is that so??) This would be a big
    change to the current model of a "disconnected" DataContext, when
    generally speaking each select or commit operation gets its own
    Connection from the pool. We'll have to open a whole can of worms
    with an open connection tied to an execution thread. Or maybe this is
    not as bad as I think it is...

    Andrus



    This archive was generated by hypermail 2.0.0 : Sun Aug 28 2005 - 16:48:28 EDT