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 2010/02/10 12:12:27 UTC
[jira] Resolved: (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 resolved ODE-671.
-----------------------------
Resolution: Fixed
Fix Version/s: 2.0-beta3
1.3.4
> 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
> Fix For: 1.3.4, 2.0-beta3
>
>
> (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.