FWD » Core Development » Database

I found this while investigating queries in #2266. The following code was constructed based real code from a customer application:

DEFINE VARIABLE lma AS LOGICAL NO-UNDO INIT YES.
DEFINE VARIABLE lmid AS INTEGER NO-UNDO INIT 0.

DEF TEMP-TABLE t1 FIELD m AS LOGICAL EXTENT 10 INIT YES.
DEF TEMP-TABLE t2 FIELD m AS LOGICAL EXTENT 10 INIT YES.

CREATE t1.
CREATE t2.

IF lmid = 0 THEN
   ASSIGN lmid = ?.

ASSIGN lma = IF AVAILABLE t1 THEN (t1.m[lmid] AND t2.m[lmid]) ELSE FALSE NO-ERROR.

MESSAGE lma.

The whole idea is that the ASSIGN expression should evaluate to UNKNOWN because the lmid is UNKNOWN and used as index for an EXTENT field.
The original exception is lost and not printed in logs. It looks like this:

Caused by: java.lang.ClassCastException: com.goldencode.p2j.util.int64 cannot be cast to com.goldencode.p2j.util.logical
    at com.goldencode.p2j.persist.$__Proxy2.isM(Unknown Source)
    at com.goldencode.p2j.testcases.AssignFail$1.body(AssignFail.java:2147)
    at com.goldencode.p2j.util.BlockManager.processBody(BlockManager.java:7053)
    at com.goldencode.p2j.util.BlockManager.topLevelBlock(BlockManager.java:6886)
    at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:252)
    at com.goldencode.p2j.util.BlockManager.internalProcedure(BlockManager.java:238)
        ...

What is wring is that RecordBuffer.Handler.invoke(Object proxy, Method method, Object[] args), in the case of EXTENT fields that have UNKNOWN index, the returned value is the same 1 ^st argument, on the consideration that it was checked by previous code and it is UNKNOWN.
Indeed, it is UNKNOWN, but the class is wrong - int64 instead of the expected logical.

The solution is, that in the event of an UNKNOWN index, to return the UNKNOWN of the correct class, ie a new logical(), in this case. The UNKNOWN_VALUE branch of the switch should look like this:

    return (property != null) ? null : FieldReference.unknownValue(method);

Ovidiu Maxiniuc wrote:

The original exception is lost and not printed in logs.

Have you determined why it is lost? This seems like valuable information to discard, and suggests we need an update to the infrastructure that discarded it.

The original exception is discarded because it is caused by an abnormalEnd() in the BlockManager so the whole unwind framework will drop it and only print on FINE log-level of the TransactionManager. P2J will proceed with rollback().

Ovidiu Maxiniuc wrote:

The original exception is discarded because it is caused by an abnormalEnd() in the BlockManager so the whole unwind framework will drop it and only print on FINE log-level of the TransactionManager. P2J will proceed with rollback().

OK, yes, I added that logging to TM recently, for this exact reason. Although it requires turning on FINE logging (which is very noisy), I think that's OK as a temporary requirement when you're diagnosing an abnormal end.