[hibernate-issues] [Hibernate-JIRA] Commented: (HB-1014) Hibernate does not remove ID's on a failed flush

[Arnout Engelen (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HB-1014?page=comments#action_24984 ] 

Arnout Engelen commented on HB-1014:
------------------------------------

I assume by 'added' you're referring to the hibernate.use_identifer_rollback property (http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configuration.html)?

It didn't appear to work for me, but that might be unrelated.

> Hibernate does not remove ID's on a failed flush
> ------------------------------------------------
>
>          Key: HB-1014
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-1014
>      Project: Hibernate2
>         Type: Bug

>   Components: core
>     Versions: 2.1.4
>  Environment: 2.1.4
> PostgreSQL
> Most common in Swing applications
>     Reporter: Thomas Meeks

>
>
> A thread about it: http://forum.hibernate.org/viewtopic.php?t=931005
> Conditions to recreate:
> 1. Create a new hibernate session (and transaction, if desired)
> 2. Create a transient object (that hibernate can persist)
> 3. Place the transient object in a known bad state (so that any attempt to persist it will fail)
> 4. Attempt to save the object, which will fail
> 5. Close session, rollback txn
> 6. Fix the error with the object
> 7. Create a new hibernate session/txn
> 8. Attempt to save the object (which will currently fail, though it should not)
> 9. Close session
> The error occurs at step 8. Because hibernate does not set the ID of the object to null, it will assume that the object is in the database. When hibernate attempts to update the object (rather than save), it will fail. This bug is particularily nasty when dealing with cascades, as all objects will be assigned numbers.
> A workaround:
> Have your DAO layer keep track of new objects and manually set the ID to null /after/ the session has closed (if you delete the ID before the session closes, hibernate will complain about the changing of IDs).
> This workaround can get quite messy, however, if one requires the use of cascades. 
> A (possible) real fix:
> Have hibernate keep track of all new entities in the session, and upon failure, iterate those entities and set their ID to null.
> Another possibility (enumerated by gavin in the thread mentioned above) is to copy the entire object tree by value, but this could cause real problems in objects with large byte arrays.
> The problem may be difficult to fix, however, I find the fact that the steps outlined above do not work to be very counterintuitive. If not fixed, this bug should be at the very least well documented. 
> The exception handling portion of the documentation does not indicate that all newly saved objects must be thrown out if the session they are saved in has an exception.

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