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() {
..verride
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 <andru..bjectstyle.org> 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
>
This archive was generated by hypermail 2.0.0 : Tue Feb 28 2006 - 14:53:43 EST