[hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-2516) hibernate.use_identifier_rollback=true doesn't seem to be having any effect

[Christian Bauer (JIRA)]

     [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2516?page=all ]
     
Christian Bauer resolved HHH-2516:
----------------------------------

    Resolution: Rejected

Identifier rollback is only used when object is _deleted_. Emmanuel apparently doesn't know that. Stay on the forum to debug your code.


> hibernate.use_identifier_rollback=true doesn't seem to be having any effect
> ---------------------------------------------------------------------------
>
>          Key: HHH-2516
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2516
>      Project: Hibernate3
>         Type: Bug

>     Versions: 3.2.2
>  Environment: Tested with Hibernate 3.2.0 GA and also 3.2.2 GA Core and Annotations+EntityManager 3.3.0 GA.
> MySQL Standard 5.0.27.  Java 1.5.0_06 (on Mac OS X).
>     Reporter: Darren Clarke
>  Attachments: testfiles.zip
>
>
> As per post entitled "Unexpected 'detached entity passed to persist' error" in the "Hibernate Annotations, EntityManager, Search, Validator, Shards" forum, original posting by darrenclarke.
> I have a Person entity that has a 1:1 with an Address entity.  Both have int PKs.  Person has an additional unique column (accountNumber).
> When I persist() a new Person that has an accountNumber that causes a unique-constraint violation (deliberately for testing purposes), catch the resulting exception and perform a rollback(), the database state is correct, but the application's internal entity state is incorrect (person.getId()==0, but person.getAddress().getId() is not 0, i.e. the PK value has not been rolled back).
> Emmanuel suggested using hibernate.use_identifier_rollback=true, but that has made no difference.
> The attached files replicate the problem (note I haven't performed proper ThreadLocal-based EntityManager creation and the like, it's just a bare-bones standalone example to replicate the problem).
> Running Main and then stepping through the stdout reveals the following:
>    [stdout]  Creating person 1 ...
>    [stdout]  Persisting person 1 ...
>    [stdout]      Prior to merge/persist, person.getId()=0, person.getAddress().getId()=0
>    [stdout]      merge/persist succeeded.
>    [stdout]  Creating person 2 (accountNumber is the same as person 1's) ...
>    [stdout]  Persisting person 2 ...
>    [stdout]        Prior to merge/persist, person.getId()=0, person.getAddress().getId()=0
>    [stdout]        Prior to rollback, person.getId()=0, person.getAddress().getId()=2
>    [stdout]        After rollback,    person.getId()=0, person.getAddress().getId()=2
>    [stdout]      Creation of new person failed due to duplicate account number (1) - retrying with different account number (2, retry# 1) ...
>    [stdout]        Prior to merge/persist, person.getId()=0, person.getAddress().getId()=2
>    [stdout]        Prior to rollback, person.getId()=0, person.getAddress().getId()=2
>    [stdout]        After rollback,    person.getId()=0, person.getAddress().getId()=2
>    [stdout]      Exception whilst persisting person 2:
> java.lang.Exception: Unable to save person
> [snip]
> Caused by: javax.persistence.PersistenceException: org.hibernate.PersistentObjectException: detached entity passed to persist: testapp.domain.Address
> [snip]
> I.e. the first persist is fine.  The second persist (with unique-constraint violation) fails, but the address ID isn't reset after the rollback.  Therefore when the second persist is retried with a valid accountNumber, the persist fails again as it believes an existing but detached address is referenced.

-- 
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