Re: isIteratedResult and SPs

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Tue Feb 14 2006 - 18:30:58 EST

  • Next message: Cris Daniluk: "Re: isIteratedResult and SPs"

    > This doesn't seem like the most intuitive way to block the auto-
    > commit.

    No it doesn't :-) It is intended for a very specific use - when you
    want to process an open cursor manually.

    > It might be nice to create an overloaded version of this
    > method that explicitly stops commits

    There are two "official" ways to avoid commit - external transactions
    and user-managed transactions. Can you explain why commit is
    undesirable. Is this a standalone ProcedureQuery, or is this
    something you are doing from TransactionDelegate?

    Andrus

    On Feb 14, 2006, at 9:51 AM, Cris Daniluk wrote:

    > In order to get stored procedures working properly, I had to override
    > the OperationObserver to return isIteratedResult = true:
    >
    > // don't commit iterated queries - leave it up to the
    > caller
    > // at the same time rollbacks of iterated queries must be
    > processed here,
    > // since caller will no longer be processing stuff on
    > exception
    > if (!observer.isIteratedResult()
    > && (getStatus() == Transaction.STATUS_ACTIVE)) {
    > commit();
    > }
    >
    > This doesn't seem like the most intuitive way to block the
    > auto-commit. It might be nice to create an overloaded version of this
    > method that explicitly stops commits :
    >
    > performQueries(DataContext, List, OperationObserver, boolean)
    >
    > Cris
    >



    This archive was generated by hypermail 2.0.0 : Tue Feb 14 2006 - 18:30:58 EST