[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-7206) Manage natural-id synchronization without flushing

Steve Ebersole (JIRA) noreply at atlassian.com
Tue Apr 3 14:48:48 EDT 2012


    [ https://hibernate.onjira.com/browse/HHH-7206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46170#comment-46170 ] 

Steve Ebersole commented on HHH-7206:
-------------------------------------

I have this working, for the most part.  But here is a "rub" condition.  I went at it a slightly different way, but your code suffers the same "rub".

Take the test case {{org.hibernate.test.naturalid.mutable.MutableNaturalIdTest#testCacheSynchronizationOnMutation}} which is what i used to test this change out in terms of actually working.  You have to remove the manual intermediate flush to get it to represent a more natural flow (and certainly the "in-line" natural-id updating flow you are advocating).  So you have:

{code:borderStyle=solid}
Session s = openSession();
Transaction t = s.beginTransaction();
User u = new User( "gavin", "hb", "secret" );
s.persist( u );
t.commit();
s.close();

s = openSession();
s.beginTransaction();
u = (User) s.byId( User.class ).getReference( u.getId() );
u.setOrg( "ceylon" );
User oldNaturalId = (User) s.byNaturalId( User.class ).using( "name", "gavin" ).using( "org", "hb" ).load();
assertNull( oldNaturalId );
assertNotSame( u, oldNaturalId );
s.getTransaction().commit();
s.close();
{code}

Basically we create an entity with natural id of ["gavin", "hb"].  We then change "hb" to "celyon" on the object and attempt to perform a lookup by the old natural id.  This *should* result in a null result because that no longer exists.  However, what really ends up happening is that the "dirty" detection finds the change and (correctly) removes the old cache entry and adds the new.  But now when the lookup on the old natural id fails it reverts to the database and the old value is still there, so that is returned.  

Aside from writing the changes to the database at the same time, the only other option I can think of is to keep track of "no longer valid" natural id resolutions (i.e., keep around the fact that ["gavin", "hb"] is no longer valid and should return null) until the next flush cycle.  Which I am not a huge fan of.

> Manage natural-id synchronization without flushing
> --------------------------------------------------
>
>                 Key: HHH-7206
>                 URL: https://hibernate.onjira.com/browse/HHH-7206
>             Project: Hibernate ORM
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 4.1.1
>         Environment: Hibernate4, database-independent
>            Reporter: Guenther Demetz
>            Assignee: Steve Ebersole
>              Labels: flush, naturalId
>
> With few code changes I think it is possible to make NaturalIdLoadAccess work with no need to rely on flush at all,
> please see following comments.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the hibernate-issues mailing list