Community
Participate
Working Groups
Build Identifier: 2.0.1 Our entities are structured as follows: @javax.persistence.MappedSuperclass abstract class AbstractBaseEntity { } @javax.persistence.Entity; abstract class AbstractEntity extends AbstractBaseEntity { } @javax.persistence.Entity; @org.eclipse.persistence.annotations.Cache(expiry = 5000) class Entity2 extends AbstractEntity { } We have activated L2 cache (default) but the expiration time for the L2 cache does not work. Without the AbstractEntity the cache configuration works. Reproducible: Always
Does it work if you place the expiry on AbstractEntity? Because of the inheritance objects of these classes will be cached in the same IdentityMap. There should likely be a validation warning or exception here to let you know this, but other than that, this is expected behavior.
Hello, Since 2 day (coincidentally) I struggle with expiry of object of a subclass. For compatibility reasons I use EclipseLink 1.0.2 with the following setup: @MappedSuperClass class A @Entity @Inheritance(strategy = InheritanceType.SINGLE_TABLE) @Cache(expiry = 7000, size = 50) class B extends A @Entity class C extends B Now, every 5 seconds (observe that expiry is 7 seconds), find(B.class, <key>) is being called for a set of primary keys. The set of loaded objects contains 1 instance of B and the rest are instances of C. Now about the behavior. During the first 7000 ms after the start-up of the application, when these clustered find(..) invocation happen more often than once in 5 seconds, all objects of B and C are first put in the cache then reused, as expected. However, when this happens exactly once in 5 seconds, I always see queries for objects of C (not expected) and only every second time for B (expected). By accessing the class descriptors of B and C and their respective CacheInvalidationPolicy objects during every clustered call to find(..), I found that B gets assigned a TimeToLiveCacheInvalidationPolicy and C -- NoExpiryCacheInvalidationPolicy. After manually applying the first to the ClassDesctiptor of C by means of a SessionCustomizer I do get expected behaviour: every second time queries are executed for the entire set of primary key. This all does not seem normal to me as I expect that inheritance subclasses (C in this case) get the same caching behavior as the inheritance root (B in this case).
yosav, Please post usage questions to the users mailing list or the newsgroup.
When I add the annotation to both entities (AbstractEntity and Entity2) it works. This makes sense if both entities are in the same IdentyMap.
Sorry - my mistake. It does NOT work.
Setting target and priority. See the following page for the meanings of these fields: http://wiki.eclipse.org/EclipseLink/Development/Bugs/Guidelines
What symptom are you seeing that indicates it does not work?
You can start two instances. Instance 1 updates the entity in a loop calling an facade method. Instance 2 reads the entity in a loop calling a facade method. Instance 2 will never see the modifiactions of instance 2 after expiry. If you remove the AbstractEntity from inheritance, instance 2 will recognize the changes after expiry.
Created attachment 223891 [details] Bug fix and tests Bug is fixed by cloning the parent descriptor's CacheInvalidationPolicy in ClassDescriptor initialization.
Fixed in trunk (2.5.0) at 50fd8fb9846d611ee2d71e58d23dde5961d24a4b 2.4.x branch checkin pending.
Checked into 2.4.x branch (2.4.2) at 5a2a333a6c5e6feeaa158dfc6c81a42676ea47d6
Created attachment 224112 [details] Testing changes (fixed time) & clone == check Minor test changes: - set DailyCacheInvalidationPolicy to have a fixed time - add CacheInvalidationPolicy instance identity == checks
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
