> Another question we have is what exactly was the "internal test regression" that caused the rollback? The company I work for (IBM) does a huge amount of functional server based testing internally. When changes are made, the OpenJPA unit tests are the first line of tests and occasionally the UTs miss a scenario that the internal tests catch. This is one of those scenarios.
As I eluded to in the JIRA, the root problem is that in the JPA 2.0 spec, the concept of Cache/CacheStoreMode/CacheRetrieveMode/etc/etc was added and this change was not honoring that contract. The crux of the problem is that the default value for CacheStoreMode is USE and the spec says[1] that elements in the cache are not to be updated. So in your example, after Foo-1[b,c] gets loaded the subsequent load of Foo-1[a] will not be reflected in the cache. I agree that most likely isn't the expected behavior, but we need to satisfy the spec. It might make sense to see how we behave if you change the CacheStoreMode to REFRESH. Start by passing the CacheStoreMode into EntityManager.find(...) and from there check to see if you can pass javax.persistence.CacheStoreMode as a persistence.xml level property. Honestly I don't have many cycles to look at this problem right now, but I'll help where I can. Thanks, Rick [1] *http://docs.oracle.com/javaee/6/api/javax/persistence/CacheStoreMode.html#USE <http://docs.oracle.com/javaee/6/api/javax/persistence/CacheStoreMode.html#USE>* -- "Does not force refresh of already cached items when reading from database." On Wed, Feb 12, 2014 at 5:03 PM, Jeff Oh <jeff...@elasticpath.com> wrote: > Hello, > > We're currently migrating an application from OpenJPA 1.2.2 to OpenJPA > 2.3.0, and have found that DataCache efficacy in our application declines > significantly from 1.2.2 to 2.3.0, to the point where our overall system > performance has declined by about 25% with the version upgrade. > > We've found that we can restore DataCache performance to 1.2.2 levels by > re-applying OPENJPA-2285< > https://issues.apache.org/jira/browse/OPENJPA-2285>, which was rolled > back due to an "internal test regression" issue. > > The behaviour we've found is this: > > Given: > > An entity Foo, with fields [a, b, c]. > Foo-1 is loaded into the datacache using a fetch group that loads fields > [a, b]. > > When: > > A query is executed that loads Foo-1 using fields [b,c]. This query is > executed twice in succession, using two different EntityManagers. > > Then: > > In OpenJPA 2.3.0, both queries result in a SQL query being run to load the > value of field c. > In OpenJPA 1.2.2, only the first query results in a SQL query being run to > load the value of field c. The second query is serviced from cache. > > Expected: > > The OpenJPA 1.2.2 behaviour seems more consistent with expected cache > behaviour. The cache cannot be expected to successfully fulfill the > request on the first invocation - but it should be able to fulfill it on > all subsequent invocations. > > The first question is, what should OpenJPA 2's behaviour be in this > circumstance? OPENJPA-2285< > https://issues.apache.org/jira/browse/OPENJPA-2285> merges the new loaded > fields into the original cached entity and recaches the entity. OpenJPA > 1.2.2 does a similar thing, except that it rejects the merge if the new > entity has an earlier version than the cached entity. Note that merging > still occurs in OpenJPA 1.2.2 if the new entity has a later version than > the cached entity. > > Another question we have is what exactly was the "internal test > regression" that caused the rollback? > > > Some potential solutions: > > 1. Merge cached and loaded data as per OPENJPA-2285/OpenJPA 1.2.2. > This minimizes database operations required. On the other hand, the merge > of cached and non-cached data raises the possibility of entities with > "mixed" data from various versions. It's probably best to reject the > object entirely if a version conflict is detected and reload the entire > object from the db (and recache) in that instance. > > 2. Load object from db using the query's fetch group and recache. > Instead of merging cached fields and db loaded fields, OpenJPA could load > the entire object using the query's fetch group. This object should be in > a consistent state, and the object in data cache could be replaced with the > newly loaded object. The disadvantage would be if there are two different > queries being run for the same entity, one with the fetch group [a, b] and > another with the fetch group [b,c], then the object in cache will "whipsaw" > back and forth between representations. This also results in more db > access than option #1. > > 3. Load object from db using the superset of the query's fetch group and > the datacache's fetch group and recache. > Instead of merging cached fields and db loaded fields, OpenJPA could load > the entire object using the union of the query's fetch group and the cached > entities' fetch group. This object should be in a consistent state, and > the object in data cache could be replaced with the newly loaded object. > The disadvantage would be it's hard to see how this could reliably extend > to entities related to the original entity that are loaded as part of the > query. However, it avoids the whipsaw problems in option #2. This option > also results in the most db access, at least initially. > > 4. Remove incomplete entities from cache. > Merge cached and loaded data together as is done currently, but remove the > cached entity afterwards. This isn't much of a solution, but at least a > sparsely loaded entity doesn't have the potential to degrade the cache > indefinitely... > > 5. Some ability to enable one or more of the solutions via a config > option, if none of these solutions are considered acceptable for "core" use. > > > If there's agreement on what behaviour folks would like to see, I'd be > happy to submit a patch. > > > Cheers, > > Jeff > > > > > > > > [http://elasticpath.com/images/ep.gif] > Jeff Oh, Sr. Software Engineer > Phone: 604.408.8078 ext. 104 > Email: jeff...@elasticpath.com<mailto:jeff...@elasticpath.com> > > Elastic Path Software Inc. > Web elasticpath.com <http://www.elasticpath.com/> | Blog getelastic.com < > http://www.getelastic.com/> | Twitter twitter.com/elasticpath < > http://www.twitter.com/elasticpath> > Careers elasticpath.com/jobs<http://www.elasticpath.com/jobs> | Community > grep.elasticpath.com <http://grep.elasticpath.com/> > > Confidentiality Notice: This message is intended only for the use of the > designated addressee(s), and may contain information that is privileged, > confidential and exempt from disclosure. Any unauthorized viewing, > disclosure, copying, distribution or use of information contained in this > e-mail is prohibited and may be unlawful. If you received this e-mail in > error, please reply to the sender immediately to inform us you are not the > intended recipient and delete the email from your computer system. > > > > -- *Rick Curtis*
