On Mon, Feb 7, 2011 at 1:41 PM, Daryl Stultz <[email protected]>wrote:
> On Mon, Feb 7, 2011 at 2:23 PM, Michael Dick <[email protected] > >wrote: > > > What it actually does is reset internal state. > > > > Thanks for the "inside information". > Upon further reading, OpenJPA is showing it's JDO roots. Evict is a hint to the PersistenceManager in the JDO spec which (conditionally) triggers the state transition. I'm not a JDO expert, but it looks like it's mainly there to tell the provider that these entities may be GC'ed. It doesn't explicitly remove them though. FWIW I've opened OPENJPA-1937<https://issues.apache.org/jira/browse/OPENJPA-1937>to update the javadoc. > > > Or you can call clear() to remove everything from > > the L1 cache which is a bit extreme. > > > > I think after failing to evict some time ago, I did clear(). Then someone > tried to update some objects after deleting some and ran into a lazy load > problem (I learned clear() detaches everything). > > > > > Presumably your code executes a find later on and you want to prevent > > reading a stale row? A JPQL query will execute against the database so > the > > results there should be up to date. > > > > Yes, a query works, but em.find(MyCase.class, 123) will return the deleted > object from L1 if I'm not mistaken. I pulled the call to clear() as it > should be unusual to call find after deleting. I can't seem to uncover any > other side effects of the deleted object hanging around in L1. > That matches what I've seen. Is the find issue a blocker for you ? -mike > -- > Daryl Stultz > _____________________________________ > 6 Degrees Software and Consulting, Inc. > http://www.6degrees.com > http://www.opentempo.com > mailto:[email protected] >
