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)