Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/JPA 2.0/cache api"
m (→Issue 5: Handle no associated descriptor for Class parameter) |
m (→Issue 5: Handle no associated descriptor for Class parameter) |
||
Line 59: | Line 59: | ||
*Doug: "3. continued...Also does not properly handle the case where the cls provided is not associated with | *Doug: "3. continued...Also does not properly handle the case where the cls provided is not associated with | ||
a descriptor." | a descriptor." | ||
− | *See contains(Class, Object) and contains(Object) | + | *See contains(Class, Object) and contains(Object). |
+ | *The class may still be associated with a Descriptor if it is a MappedSuperclass though. | ||
====Issue 6: Add support for @MappedSuperclass descriptors==== | ====Issue 6: Add support for @MappedSuperclass descriptors==== |
Revision as of 13:00, 23 March 2010
Contents
- 1 Cache APIs
- 1.1 Issue Summary
- 1.2 General Solution
- 1.3 Work Required
- 1.4 Implementation Details
- 1.5 Refactor 20100322
- 1.5.1 Analysis
- 1.5.1.1 Issue 1: Fix evict() to handle non-Entity classes
- 1.5.1.2 Issue 2: Refactor to get IdentityMapAccessor state through EMF reference
- 1.5.1.3 Issue 3: Refactor dependencies to use Interfaces instead of Impl subclasses
- 1.5.1.4 Issue 4: Handle no CMPPolicy case for getId()
- 1.5.1.5 Issue 5: Handle no associated descriptor for Class parameter
- 1.5.1.6 Issue 6: Add support for @MappedSuperclass descriptors
- 1.5.1.7 Issue 7: Throw an IAE for Interfaces and Embeddable classes passed to evict()
- 1.5.2 Design
- 1.5.3 Implementation
- 1.5.4 Testing
- 1.5.1 Analysis
- 1.6 References
Cache APIs
JPA 2.0 Root | Enhancement Request
Issue Summary
In JPA 2.0 the specification has added a Cache API obtainable from an EntityManagerFactory. This simple API provides developers with rudimentary access and control of a second level cache. User's can interrogate the cache through a contains(Class, Object) API call and cause cached data to be evicted from the cache through an evict(Class, Object), evict(Class) or evictAll() API call.
See The JPA 2.0 Final Release Specification section 7.10 p.306 for details.
General Solution
Should be simple to equate evict to invalidate.
Work Required
- Develop tests
- approx 1 day
- Implement API
- approx 2 days
Implementation Details
The Cache API consists of following 4 methods
- contains(Class cls, Object primaryKey) --- checks whether the class with the specified primary key
- is contained in IdentityMap.
- evict(Class cls, Object primaryKey) --- invalidates the specified object in the IdentityMap
- evict(Class cls) --- invalidates the specified class in the IdentityMap.
- evictAll() --- Invalidates all classes in the IdentityMap.
Refactor 20100322
- The following details describe changes to the original SVN 2896 implementation of Dec 2008 that will arrive in Trunk around April 2010.
- The implementation was modified on the following dates as follows...
- 20100201: Rev# 6463 - bug# 301063 : Refactor CacheImpl to implement the EclipseLink API interface JpaCache (which implements Cache from JPA 2.0 via the new functions - clear(), clear(Class), clearQueryCache(), clearQueryCache(queryName), timeToLive(Object), isValid(Object), isValid(Class, id), print(), print(Class), printLocks(), validate(), getObject(Class, id), getObject(Object), putObject(Object), removeObject(Class), removeObject(Class, id), containsObject(Object), evictObject(Object), getId(Object)
- 20100126: Rev# 6406 - bug# 298985 : Refactor Vector usage to Id or CacheId
- 20091124: Rev# 5875 - bug# 272895 : Check invalidation during contains()
- 20090513: Rev# 4170 - bug# 275953 : Bootstrap performance and compatibility
Analysis
Issue 1: Fix evict() to handle non-Entity classes
Issue 2: Refactor to get IdentityMapAccessor state through EMF reference
- Doug: "1. Unsure if we need to hold all of this state or just hold the EMF and access
the necessary IdentityMapAccessor through this access."
- We should also get the serverSession from the EMF when required instead of caching it on the CacheImpl.
- Wherever we see... ServerSession this.serversession
- replace it with...
- emf.getServerSession()
Issue 3: Refactor dependencies to use Interfaces instead of Impl subclasses
- Doug: "2. We will need to support more then just ServerSession so we need to have
impls such as this just rely on more general interfaces for the shared session such as Session or DatabaseSession interfaces."
Issue 4: Handle no CMPPolicy case for getId()
- Doug: "3. The createPKVector does not handle the case where the descriptor does not
have a CMPPolicy. This occurs when bootstrapping from native metadata."
- Avoid a possible NPE on the return from descriptor.getCMPolicy()
- createPKVector changed to createPrimaryKeyFromId to refactor out Vector usage in bug 298985
Issue 5: Handle no associated descriptor for Class parameter
- Doug: "3. continued...Also does not properly handle the case where the cls provided is not associated with
a descriptor."
- See contains(Class, Object) and contains(Object).
- The class may still be associated with a Descriptor if it is a MappedSuperclass though.
Issue 6: Add support for @MappedSuperclass descriptors
- Doug: "4. Should we support passing in MappedSuperclass or general types from the
entity inheritance tree? I believe we should."
- MappedSuperclasses do not represent real descriptors - they add functionality to concrete Entities that inherit from them - therefore they should not be evicted.
- As Gordon mentions, we should throw an IllegalArgumentException if a Class (abstract class) representing a MappedSuperclass is passed into evict(Class).
Issue 7: Throw an IAE for Interfaces and Embeddable classes passed to evict()
- Should we throw an IllegalArgumentException for interfaces or embeddables passed into evict(class) as well?