Skip to main content

[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
-----Original Message-----
From: Douglas Clarke
Sent: January 12, 2010 6:57 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: RE: [eclipselink-dev] Q: FetchPan Extension and JPQL Query Cache

Since nobody responded I filed a bug with my suggested solution.
 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=299353
 
Doug
-----Original Message-----
From: Douglas Clarke
Sent: December 7, 2009 10:49 AM
To: Eclipselink-Dev (E-mail)
Subject: [eclipselink-dev] Q: FetchPan Extension and JPQL Query Cache

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
 

Back to the top