You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Rafal Rusin (JIRA)" <ji...@apache.org> on 2009/10/03 21:15:23 UTC

[jira] Assigned: (ODE-671) clean up queries in HLargeData are too broad

     [ https://issues.apache.org/jira/browse/ODE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rafal Rusin reassigned ODE-671:
-------------------------------

    Assignee: Rafal Rusin

> clean up queries in HLargeData are too broad
> --------------------------------------------
>
>                 Key: ODE-671
>                 URL: https://issues.apache.org/jira/browse/ODE-671
>             Project: ODE
>          Issue Type: Bug
>            Reporter: Alexis Midon
>            Assignee: Rafal Rusin
>
> (Regression presumably introduced by ODE-641)
> The clean up queries executed in ProcessDaoImpl#deleteMessages might return some null values. These null values are then used in a IN operator, which Derby does not like at all. The query hangs on for ever, no timeout, no warning, nothing.
> For instance: 
> deleteByIds(HLargeData.class, getSession().getNamedQuery(HLargeData.SELECT_MEX_LDATA_IDS_BY_INSTANCES_1).setParameterList("instances", instances).list());
> a. HLargeData#SELECT_MEX_LDATA_IDS_BY_INSTANCES_1 = select m.messageData.id from HMessage m where m.messageExchange.instance in (:instances) 
>   This returns a list of null values
> b. deleteByIds executes: delete HLargeData where id in(null, null, null), which hangs on for ever.
> The fix is to add a 'is not null' clause in a.
> I used the following Derby properties to gather information.
> -Dderby.drda.traceAll=true -Dderby.locks.monitor=true -Dderby.language.logStatementText=true -Dderby.stream.error.field=java.lang.System.err -Dderby.stream.error.logSeverityLevel=0 -Dderby.locks.deadlockTimeout=3 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.