[ https://issues.apache.org/jira/browse/OPENJPA-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965010#action_12965010 ]
Robert Krier commented on OPENJPA-1899: --------------------------------------- Hi Rick, I have re-uploaded the test case zip file with the ASF inclusion option. Let me know if you still have problems with it. I can send it directly to you if needed. The entities are in src/com/foo/bar/models and the test cases are in src/com/foo/bar/app. It should be pretty straight forward to see what's going on. If something isn't clear, let me know and I'll be happy to assist. Thanks for your response on this. Bob ----------------------------------------------------------------------------->> - > Evict from L2 of a object causes secondary objects to never be loaded in graph > ------------------------------------------------------------------------------ > > Key: OPENJPA-1899 > URL: https://issues.apache.org/jira/browse/OPENJPA-1899 > Project: OpenJPA > Issue Type: Bug > Components: kernel > Affects Versions: 2.0.0, 2.0.1 > Environment: N/A > Reporter: Robert Krier > Priority: Blocker > Attachments: evictproblem.zip, evictproblem.zip > > > I have a simple example. A customer has a reference to an address and a > (primary) contact (an extension of person). Find the customer, get the > contact and evict it from L2. Now find the customer again using a new entity > manager. Begin a Tx and change the address of the contact and then call > Customer.getPrimaryContact() (this is important) Rollback the Tx. Now find > the customer again using another new EntityManager and call > Customer.getPrimaryContact().getAddress(). The address associated with the > contact is Null and not the original address as expected. The same scenario > works fine under OpenJPA 1.2.2. > The reason this is a big problem for us is we use L2 caching in our > application and the application is clustered. The same problem occurs if > different nodes in the cluster operate on the same objects. In a cluster > "evict" is not directly called, but the RemoteCommitProvider will evict the > L2 and create the same problem. > I have attached example code to reproduce the problem using a single JVM and > calling Evict. I also have another example where you can deploy the code on > two nodes in a cluster and see the problem occurs that way as well. Each > example contains Unix shell scripts and Windows cmd files as well. Each are > paired for JPA 1.0 and JPA 2.0. Again, the problem only occurs under JPA 2.0. > This is a block for us. We cannot ship our product with this type of problem > as it means objects and their graph can be corrupted. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.