[
https://issues.apache.org/jira/browse/OPENJPA-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091651#comment-14091651
]
brian yoder edited comment on OPENJPA-2523 at 8/9/14 5:10 AM:
--------------------------------------------------------------
Found the issue. There is something broken in the actual key used downstream.
For example this somehow works:
OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
IntId key1 = new org.apache.openjpa.util.IntId(X.class, id);
kem.getEntityManagerFactory().getStoreCache().evictAll(X.class, key1);
It would seem that the downstream API should generate the proper key (IntId)
when trying to remove it from the cache, but it doesn't, and seems to miss that
part. So the workarround is to figure out what type of key it will be, and
pass that into the evict call.
I am amazed that nobody else has reported this issue yet. I guess the lack of
documentation on this feature may explain it. I had to plugin ehcache in order
to figure out this was the issue, and I have to say that ehcache seems very
nice with regards to controlling separate caches per entity, and other features
(disk, max cache size). I wonder if OpenJPA should move to using the ehcache
plugin since it is also supported for distributed (clustered) environments.
That said it's still a bug, needs to be fixed.
was (Author: byoder):
Found the issue. There is something broken in the actual key used downstream.
For example this would work:
OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
IntId key1 = new org.apache.openjpa.util.IntId(X.class, id);
kem.getEntityManagerFactory().getStoreCache().evictAll(X.class, key1);
It would seem that the downstream API should generate the proper key (IntId)
when trying to remove it from the cache, but it doesn't, and seems to miss that
part. So the workarround is to figure out what type of key it will be, and
pass that into the evict call.
I am amazed that nobody else has reported this issue yet. I guess the lack of
documentation on this feature may explain it. I had to plugin ehcache in order
to figure out this was the issue, and I have to say that ehcache seems very
nice with regards to controlling separate caches per entity, and other features
(disk, max cache size). I wonder if OpenJPA should move to using the ehcache
plugin since it is also supported for distributed (clustered) environments.
That said it's still a bug, needs to be fixed.
> evict by OID is broken
> ----------------------
>
> Key: OPENJPA-2523
> URL: https://issues.apache.org/jira/browse/OPENJPA-2523
> Project: OpenJPA
> Issue Type: Bug
> Environment: JPA 2.3.0
> Reporter: brian yoder
>
> I cannot seem to get the evict by OID working. When I use evict by class
> that works, but what I really want to do is to just evict a single entity.
> Here is my scenario:
> 1) Bean managed EJB uses a native SQL to modify an Entity. This does begin &
> commit.
> 2) After the commit it makes a call to another EJB, but that call is
> returning stale data.
> I have tried:
> OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
> kem.getEntityManagerFactory().getCache().evict(X.class, id);
> But that doesn't work, but this works:
> OpenJPAEntityManager kem = OpenJPAPersistence.cast(em);
> kem.getEntityManagerFactory().getCache().evictAll(X.class);
> Am I the only one having issues with evict by ID?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
