Bug 261076 - JPA PK QUERY DOES NOT CHECK CACHE AND ISSUES SQL
Summary: JPA PK QUERY DOES NOT CHECK CACHE AND ISSUES SQL
Status: RESOLVED FIXED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Eclipselink (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P2 minor with 2 votes (vote)
Target Milestone: ---   Edit
Assignee: Nobody - feel free to take it CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2009-01-14 14:32 EST by Shaun Smith CLA
Modified: 2022-06-09 10:34 EDT (History)
2 users (show)

See Also:


Attachments
patch for cache hits and several other bugs (61.05 KB, patch)
2010-05-12 12:32 EDT, James Sutherland CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Shaun Smith CLA 2009-01-14 14:32:42 EST
A simple PK query like "select o from MyEntity o where o.id = :id" should check the cache for early return but is always resulting in a SQL query.  In my tests, an em.find() against the same EntityManager does not result in SQL.  This is a regression but I'm not sure how far back this has been broken.

This problem is also reproducible in EclipseLink 1.0.2.

   Shaun

Example Test:


	@Test
	public void testPkQueryHitsCache() {
		Map<String, Object> properties = new HashMap<String, Object>();
		properties.put("eclipselink.ddl-generation", "drop-and-create-tables");
		properties.put("eclipselink.ddl-generation.output-mode", "database");
		EntityManagerFactory emf = Persistence.createEntityManagerFactory("PkQueryTest", properties);
		QuerySQLTracker tracker = new QuerySQLTracker(JpaHelper.getServerSession(emf));	
		EntityManager em = emf.createEntityManager();
		// fixture setup
		em.getTransaction().begin();
		MyEntity entity = new MyEntity();
		entity.setName(String.valueOf(Calendar.getInstance().getTimeInMillis()));
		em.persist(entity);
		em.getTransaction().commit();
		// test find
		tracker.reset();
		Object result = em.find(MyEntity.class, entity.getId());
		Assert.assertNotNull(result);
		Assert.assertEquals("no select", 0, tracker.getTotalSQLSELECTCalls());
		// test pk query
		tracker.reset();
		result = em
			.createQuery("select o from MyEntity o where o.id = :id")
			.setParameter("id", entity.getId())
			.getSingleResult();
		Assert.assertNotNull(result);
		Assert.assertEquals("no select", 0, tracker.getTotalSQLSELECTCalls());
	}
Comment 1 Tom Ware CLA 2009-01-21 10:25:53 EST
What version is this a regression from?

Comment 2 Tom Ware CLA 2009-01-21 13:23:53 EST
Targetting for 1.1X since this should be considered a candidate for a patch set after 1.1
Comment 3 James Sutherland CLA 2009-01-28 14:45:41 EST
This has never worked, JPQL queries do not get cache hits by default.  They are executed as ReadAllQuery's.  You can configure this, use the query hint "eclipselink.cache-usage"="CheckCacheByPrimaryKey".

or,
"eclipselink.query-type"="ReadObject"

The issues as to why you need to set the hint include:
- When the query is created we don't know if getResultList() or getSingleResult() will be used, so always use a ReadAllQuery.
- JPA requires an error if the query returns more than one row, so a ReadAllQuery is used for getSingleResult()
- We don't know the JPQL is a primary key query without extra processing.

We might want to try to default to using ReadObject if a pk query and getSingleResult() is used, or at least have some global config default or something.
Comment 4 Doug Clarke CLA 2009-04-08 11:59:45 EDT
I have verified the usage of hints and also agree that the default usage can be confusing to users who just expect cache hits. Deferring to 2.0 for now.
Comment 5 Peter Krogh CLA 2009-11-27 13:40:54 EST
This bug fix did not make the cut off for 2.0.0. We are deferring the bugs to Future where we can properly sort them all together based on community votes and severity. We will then assign them accordingly to future patch sets and releases.
Comment 6 Peter Krogh CLA 2009-11-30 11:36:00 EST
Changing the priority of the bugs that have been recently triaged to future.  Targetting them to P2 will differentiate them from the P3s that have been triaged into future earlier.
Comment 7 James Sutherland CLA 2010-05-12 12:32:32 EDT
Created attachment 168193 [details]
patch for cache hits and several other bugs
Comment 8 James Sutherland CLA 2010-05-12 12:48:14 EDT
SVN trunk commit: Bug#261076 JPQL cache hits

Also bugs, 298830, 307164, 255535, 261674, 264275

Changes:
- Added method to check if an expression is by primary key
- Changed pagination alias to use a1, a2, etc. instead of field names which can conflict, removed maxAliasLength
- Fixed logging type
- Removed some unnecessary getClass in registerNotRegisteredNewObjectForPersist
- Added missing properties to query copying
- Fixed cache check to check cache bypass flag
- Disable cache check in ReadObjectQuery prepare if not a primary key expression
- Create primary key JPQL queries as ReadObjectQuerys
- Allow getResultList, getResultCollection if the query is a ReadObjectQuery
- Fixed ElementCollection default mapping to use owning descriptor for embeddables
- Fixed generics support to handle collection of a nested generic type

- Added test for ElementCollection from an Embeddable
- Added test for nested generics in Entity class and m-1, 1-m relationship
- Added test for JPQL cache hits
- Added test for native query hints
- Exclude complex like tests unless Oracle Corporation
Comment 9 Eclipse Webmaster CLA 2022-06-09 10:16:52 EDT
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
Comment 10 Eclipse Webmaster CLA 2022-06-09 10:34:55 EDT
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink