You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Oliver Gierke (JIRA)" <ji...@apache.org> on 2016/09/23 10:18:20 UTC
[jira] [Created] (OPENJPA-2668) CriteriaQuery instances should not
change their state based on Query instances created from them
Oliver Gierke created OPENJPA-2668:
--------------------------------------
Summary: CriteriaQuery instances should not change their state based on Query instances created from them
Key: OPENJPA-2668
URL: https://issues.apache.org/jira/browse/OPENJPA-2668
Project: OpenJPA
Issue Type: Bug
Components: jpa
Affects Versions: 2.4.1
Reporter: Oliver Gierke
JPA has a two-step, programatic query creation process: first, you create a {{CriteriaQuery}} to build up the general query structure, add constraints on it etc. Then you take that instance and create a {{(Typed)Query}} instance from it using the currently available {{EntityManager}} and bind parameters to it.
According to [reports we got for Spring Data JPA|https://jira.spring.io/browse/DATAJPA-969], the latter step changes the state of the {{CriteriaQuery}} instance, so that subsequent creations of {{Query}} instances from it (and subsequent parameter bindings in turn) don't actually get applied correctly.
Even if the subsequent creation and parameter binding got applied, that change of state in {{CriteriaQuery}} instances is problematic in concurrent access scenarios as the bindings might override each other partially.
Generally speaking I'd recommend to keep the {{CriteriaQuery}} instances immutable with regards to the creation of {{Query}} instances from them and the subsequent handling of those {{Query}} instances.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)