[hibernate-issues] [Hibernate-JIRA] Resolved: (HHH-2064) Delete not always executing

[Christian Bauer (JIRA)]

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

    Resolution: Incomplete

> Delete not always executing
> ---------------------------
>
>          Key: HHH-2064
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2064
>      Project: Hibernate3
>         Type: Bug

>   Components: core
>     Versions: 3.2.0 cr1, 3.2.0.cr2, 3.2.0.cr3, 3.2.0.cr4
>  Environment: MySQL (latest stable), XP/Linux, hibernate 3.2.0.cr4, Spring 2.0-rc3 
>     Reporter: Jasper Rosenberg

>
>
> This case I just ran into works in 3.1.3 but fails in 3.2.0 Release Candidates (1-4).
> In a single JTA transaction I execute unit test:
>         personManager.save(firstName, lastName, email, phone, password);
>         Person person = personManager.get(email); // Not the PK
>         assertNotNull(person);
>         personManager.delete(person); // Deletes by PK
>         person = personManager.get(email); // Not the PK
>         assertNull(person);
> personManager is just a DAO that uses a Spring HibernateTemplate to call save/delete/get on the underlying Session.
> In 3.1.3, the final "assertNull(person)" succeeds.  
> In 3.2-RC4 it fails
> Also, if I replace that final get with:
>         person = personManager.get(person.getId()); // Get by PK
> Then the assertion succeeds.
> When I turn on logging for org.hibernate.SQL, I can see in 3.2-RC4 the delete is never executed (unlike in 3.1.3).  If I had to make a total guess, I would suspect that in 3.2-RC4 the delete it only getting applied to the session cache, and never making it to the database for some reason.  Then, since the get(email) is not by primary key, it skips the cache (where it has been removed) and finds it still in the database.
> Sorry I am unable to give you a discrete case you can run to reproduce this issue (there are a stupid number of dependencies), but hopefully this case will trigger a lightbulb to go off for the developer who was last working in this portion of the code.

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