[hibernate-issues] [Hibernate-JIRA] Commented: (EJB-409) EAGER fetched collection + Cascade.PERSIST generates broken behavior on session.update

[Hardy Ferentschik (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/EJB-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32139#action_32139 ] 

Hardy Ferentschik commented on EJB-409:
---------------------------------------

According to the persistence spec the following is the semantics of the flush operation (which is called at transaction commit):

The semantics of the flush operation, applied to an entity X are as follows:
- If X is a managed entity, it is synchronized to the database.
  * For all entities Y referenced by a relationship from X, if the relationship to Y has been annotated with the cascade element value cascade=PERSIST or cascade=ALL, the persist operation is applied to Y.
  *For any entity Y referenced by a relationship from X, where the relationship to Y has not been annotated with the cascade element value cascade=PERSIST or cascade=ALL ...
		
Our case we have the first option and hence persist will be applied to the referenced entity. Regarding persisting of entities the spec says further:

- If X is a detached object, the EntityExistsException may be thrown when the persist operation is invoked, or the EntityExistsException or another PersistenceException may be thrown at flush or commit time.

So really, the problem is that according to the spec a exception should be raised. However, to determine whether the entity is new or detached one would have to do another select which is exactly what merge() does. The semantics of the JPA spec does not allow the usecase given in the testcases.

There is of course also the question, why the pure Hibernate testcase behaves differently. We should investigate this.

> EAGER fetched collection + Cascade.PERSIST generates broken behavior on session.update
> --------------------------------------------------------------------------------------
>
>                 Key: EJB-409
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-409
>             Project: Hibernate Entity Manager
>          Issue Type: Bug
>    Affects Versions: 3.2.1
>            Reporter: Anthony Patricio
>         Attachments: HBCoreTestCase.zip, HEMTestCase.zip
>
>
> I didn't really know where to log this extremely weird bug.
> Customer 1--* Contact
> Bidirectional.
> Collection annotated with 
>     @OneToMany(fetch=FetchType.EAGER, mappedBy="customer")
>     @Cascade({CascadeType.PERSIST})
> Step 1: load a Customer (contacts are transparently retrieved) and detach the graph.
> Step 2: re attach using session.update
> --> session tries to insert into CONTACT table
> Weird things: 
> - works with @OneToMany(fetch=FetchType.LAZY, mappedBy="customer")
> - works if CascadeType.PERSIST is removed
> - works with 100% plain hibernate (mapping files + session APIs (via session Factory, see test based on hb core template)
> - fails with 50% plain hibernate (mapping files + EM APIs to obtain HB session)
> - I also tried to use HEM + hb plain mapping files --> this is failing, that's why I raised the issue in HEM project.
> I'm attaching 2 testcases: one using HEM test template (failing test) and one using HB Core template (passing test).
> This use case is not so exotic and the problem may hide something more critical.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira