[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[eclipselink-dev] FYI: Bug 299353 - EJBQueryImpl.getDatabaseQuery() will return clone if DatabaseQuery shared (cached)
|
Just
an FYI ...
As
part of Bug 299353 that I am about to check into trunk the functionality of
EJBQueryImpl.getDatabaseQuery() will change so that it clones the wrapped
DatabaseQuery if it is shared from the JPQL parse cache (see Project). This is
intended to address the situation where users unwrap the native query to apply
additional configuration to it. If they do this now it could return the shared
version and thus corrupt the query cache for future use. The new implementation
uses the same logic as when a query hint is applied that will change the state
of the native query.
For
internal use within EJBQueryImpl I have added
getDatabaseQueryInternal().
Doug
Since nobody responded I filed a bug with my suggested
solution.
Doug
Committers,
I have been
working with some customers on the http://wiki.eclipse.org/EclipseLink/Development/Incubator/Extensions/FetchPlan extension
incubator. This functionality uses a QueryRedirector to post process a query
forcing specified relationships to be instantiated so that the resulting
entities are available to serialize with the required depth of
relationships. The extension also stores the FetchPlan within the native
query using its properties.
The challenge I
am running into is that our JPQL based query cache stores native queries
based on the JPQL string used to create them. If you then modify the state
of the native query by unwrapping it from the JPA query instance you are in
fact modifying the cached native query. This means that the subsequent
EntityManager.createQuery("...") calls with the same JPQL string will get
the cached native query with the previous configurations applied which
means we are leaking config between query executions.
Before filing
bugs on the issue I wanted to figure out who knows this code best and can
help me work-around it effectively in the shipped versions and what we
should be doing going forward.
Q1: Is there a
way to avoid using the query cache when requesting the query's
creation?
Q2: Is there a
recommended way to avoid corrupting the query cache when modifying the
native query?
Doug
