Cris,
Is this still a problem? Transaction.performQueries(..) is deprecated
and indeed attempts to commit internally. Can you run the
ProcedureQuery directly via DataContext? It should pick up the same
thread transaction.
Andrus
On Feb 28, 2006, at 10:53 PM, Cris Daniluk wrote:
2 weeks later :)
My delegate invokes:
ProcedureQuery updateQuery = (ProcedureQuery)
dataContext.getEntityResolver().getQuery("MergeDocumentCopy");
updateQuery.addParameter("documentID", glinID);
updateQuery.addParameter("userID",
SessionContext.getSessionContext().getSecurityPrincipal().getUserId
());
transaction.performQueries(dataContext,
Collections.singleton(updateQuery), new DefaultOperationObserver() {
@Override
public boolean isIteratedResult() {
return true;
}
});
Note that I am invoking performQueries on the willCommit(Transaction),
and not on the context itself. In fact, I'm relatively convinced that
if I were to skip the TransactionDelegate altogether and simply pass
this modified OperationObserver to the dataContext.performQueries, it
would do precisely the right thing.
Perhaps this could be tweaked into cool functionality?
On 2/14/06, Andrus Adamchik <[EMAIL PROTECTED]> wrote:
On Feb 14, 2006, at 6:47 PM, Cris Daniluk wrote:
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?
Running it from a TransactionDelegate. It is happening after a
ton of
insert/updates, but before the overall commit. I would be okay
with it
committing, except that after it commits, the DataContext tries to
again and blows up.
That's very strange. Double commit shouldn't happen. Could you post
the code from the delegate that executes a query?
Andrus
