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.
