[Mulgara-dev] 2.1.6, SOAP, Autocommit and Transactions

[Paul Gearon]

On Tue, Jan 12, 2010 at 2:55 PM, David Smith <DMS at viewpointusa.com> wrote:
> Gentlemen,
>
> I'm trying to track down a change in behavior that snuck up on me.
>
> Problem:
> ITQL inserts/delete hanging (or not returning for a really long time).

This *might* have been caused by the bug you found below.

> Situation:
> Using Mulgara 2.1.4 in production, duplicated problem with 2.1.6
> Using SOAP (I know).
>
>>>> What is the expected behavior for transactions, exceptions and
> timeouts in SOAP calls? <<<

In all honesty? I don't know. I've never looked at how the SOAP setup
works. I've always meant to, but there always seems to be something
more important.

> In general, when I need to perform updates (delete, insert) it will be
> within a single SOAP call, surrounded by  AutoCommit OFF, ON statements.
> I need to know when the update fails, and how to recover.

Looking at the bug, I'm thinking that perhaps an exception is being
thrown in these operations, leaving the system in a state that it
never tries to recover from.

> Further Description
> There's been a change in behavior (not sure when it started),
> in that what used to happen if a second (or third, etc) thread attempted
> to perform an operation while a first thread holds the writelock
> (autocommit off),
> is that an exception would be thrown (usually indicating
> MulgaraTransactionException).

If it's what I think it is, then I suspect that a timeout is happening
before you get this.

> In the past I was able to dig through the exception text and know
> whether I needed to rollback or simply retry the operation.
>
> What I am currently seeing that that the second thread (SOAP call)
> hangs, and does not return.
>
> If I artificially shorten the <TransactionTimeout> in conf file, I can
> get an error like:
>
> =========
> javax.xml.soap.SOAPException: ItqlInterpreter error - Query failed:
> transaction-timeout
> Caused by: (MulgaraTransactionException) Attempt to activate failed
> transaction
> Caused by: (MulgaraTransactionException) transaction-timeout
> =========
>
> I need to help tracking down this issue.

Let's try addressing the bug and then go from there....

> Other puzzles:
>
> I don't know how this relates, but I have also seen (occasionally) the
> following log entries:
>
> 2010-01-11 16:21:23,761 [RMI TCP Connection(108)-10.3.3.51] -
> org.mulgara.resolver.MulgaraTransactionFactory - Terminating session
> while holding writelock:org.mulgara.resolver.DatabaseSession at 2ee02595:
> org.mulgara.resolver.MulgaraInternalTransaction at 1c1150fb
> 2010-01-11 16:21:23,793 [btpool0-13 -
> /webservices/services/ItqlBeanService] -
> org.mulgara.itql.ItqlInterpreterBean - Execute query failed.  Returning
> error
> java.lang.ClassCastException: org.mulgara.query.operation.Deletion
> cannot be cast to org.mulgara.query.operation.TxOp
>        at
> org.mulgara.itql.TqlAutoInterpreter.updateConnectionsForTx(TqlAutoInterp
> reter.java:362)
>        at
<snip/>

Looking at the code, there is a bug that presumes that all operations
that make it into the body of this method are commits or rollbacks.
However, if autocommit has just changed during an operation (something
that can now be temporarily turned off in order to group some
operations together) then other operations can make it in there as
well. Unfortunately, there is a cast based on this incorrect
assumption, which is throwing the exception.

Try changing line 362 in
querylang/java/org/mulgara/itql/TqlAutoInterpreter.java from:
  handleTxOp((TxOp)cmd);
to:
  if (cmd.isTxCommitRollback()) handleTxOp((TxOp)cmd);

This will prevent the errors you've been seeing in the logs. I'm
hoping that it will also fix the other problems as well.

Regards,
Paul Gearon