[
https://issues.apache.org/jira/browse/OPENJPA-2668?focusedWorklogId=232032&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-232032
]
ASF GitHub Bot logged work on OPENJPA-2668:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 24/Apr/19 11:55
Start Date: 24/Apr/19 11:55
Worklog Time Spent: 10m
Work Description: michaelwiles commented on pull request #40:
[OPENJPA-2668] fix for execution of a CriteriaQuery leaking into CriteriaQuery
state
URL: https://github.com/apache/openjpa/pull/40
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 232032)
Time Spent: 20m (was: 10m)
> 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 Drotbohm
> Assignee: Mark Struberg
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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
(v7.6.3#76005)
