Bugzilla – Full Text Bug Listing
| Summary: | Duplicate Entities | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Bernard Missing name <bht237> | ||||
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> | ||||
| Status: | CLOSED INVALID | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | eclipselink.orm-inbox, michael.f.obrien, mitesh.meswani, petr.jiricka | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| URL: | http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05912.html | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Bernard Missing name
Bernard, Hi, I have not noticed this running in the latest GlassFish 3.0.1 and 3.1 still in beta. I have only run container managed @PersistenceContext injection so far and not application managed RESOURCE_LOCAL. In your EclipseLink-users forum post you state that JUnit RESOURCE_LOCAL is fine and this occurs on the container. could you post your persistence.xml and your entities/mappedSuperclasses so we can compare relationships and object hierarchies. http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05912.html thank you Created attachment 189078 [details]
Testcase reproduces bug
This testcase includes everything to reproduce the bug except the libraries. Please refer to the included README file for more details.
I am very nervous about the fact that the failure is not reproducible with the included JUnit test that uses -javaagent to enable weaving.
I am very keen to learn from you - any suggestions on improving the code are highly appreciated, especially in the area of the testing.
>I'll take a look at it in the next 24 hours.
I have not mixed container managed @PersistenceContext injection with a JAXB @XmlRegistry factory before. Your issue may be related to JAXB-JPA integration and how detached entities created via JAXB are merged into the EM - just guessing at this point until I go through your NetBeans code.
Thanks for providing a test case that reproduces the issue. Nothing describes give situation like running code :). Your test injects a JTA EntityManager into StatelessSessionBean. The method of this bean called is annotated with @TransactionAttribute(value=TransactionAttributeType.NOT_SUPPORTED). This results in no transaction being active while executing the method. The spec requires each access of the injected EM to return detached entities[1]. This results in your call to em.find() to give a different instance than the one returned by the query. This of course does not happen from your unit test because the EM there is RESOURCE_LOCAL and the persistence context lasts through your method call. I would suggest you to remove the @TransactionAttribute annotation from the method to make your code work as you expect [1] From section 7.6.1 of JPA 2.0 spec / 7.6.1 Container-managed Transaction-scoped Persistence Context The application can obtain a container-managed entity manager with transaction-scoped persistence context bound to the JTA transaction by injection or direct lookup in the JNDI namespace. The persistence context type for the entity manager is defaulted or defined as PersistenceContext- Type.TRANSACTION. A new persistence context begins when the container-managed entity manager is invoked[76] in the scope of an active JTA transaction, and there is no current persistence context already associated with the JTA transaction. The persistence context is created and then associated with the JTA transaction. The persistence context ends when the associated JTA transaction commits or rolls back, and all entities that were managed by the EntityManager become detached. If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will immediately become detached at the end of the method call. / >Mitesh, yes, I agree that a transaction type of NOT_REQUIRED will temporarily suspend any existing transaction.
In the case of this session bean which not EXTENDED - the annotated method will not participate in container managed transactions.
Thank you for triaging this one.
Mitesh, Thank you for your explanation, which will help me to avoid this and help me to structure my testcases to match the behavior of the container. Did NetBeans generate this code? Or did you write it by hand? In case NetBeans generated incorrect code, it would be great if you could file a bug against NetBeans - thanks. NetBeans did not generate any of the persistence related code so it is ok. >EclipseLink user has same issue solved by changing from the NOT_REQUIRED transaction type - which suspends the transaction for the life of the method it annotates - to the default REQUIRED. http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg05961.html The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |