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

[Guenther Demetz (JIRA)]

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

Guenther Demetz edited comment on HHH-7206 at 4/3/12 7:30 AM:
--------------------------------------------------------------

Hi Steve,
>>Another thing to keep in mind is that there is absolutely no need to perform the synch code in resolveNaturalId in cases where the natural id is immutable.

I'm already aware of this, just not noticed it yet here, because I tried to be as sintetic as possible and because also hibernate4.1.1 does call autoFlushIfRequired() in resolveNaturalId even if natural id is immutable, so that's a todo which has to do be fixed anyway.

>>Another issue here is that the proposed change is updating the second level cache very prematurely. Basically it is "bleeding" un-written and un-committed changes from the session into the second level cache for other sessions to see.

Other sessions do never pick up uncommitted changes from the second level cache (that would be a big issue indeed)!
-in the case you use 2L-Cache with transactional CacheConcurrencyStrategy for example Infinispan
  the other session always see last commited cache entry (InfiniSpan is a multi-version-capable cache for this purpose)
-in the case you use 2L-Cache with read-write CacheConcurrencyStrategy
  the cached entry gets locked until the end of the transaction so that other sessions don't pick up an uncommited value.
It is true, that the proposed change is updating the second level cache rather early,
but as the user is more likely to commit rather than rollback his transaction finally, this should not be a problem.
Last but not least also a regular flush could occur already in the first phases of a transaction, with the identical effects, true or not?

>>You calculate the dirtiness and if dirty you update the natural-id xrefs but then just throw away the calculation. This is the concern I was addressing.

Sorry, but I cannot follow your argumentation: even if we would write just the natural-id changes to the database,
on every next flush that entity gets again checked for dirtiness anyway. Writing just the detected natural-id changes immediately to the database, don't saves hiberante from absolutely nothing in terms of total work amount IMO, in contrary:
you would split up the changes in more parts needing in total up to 2 update-executions instead to a single one.
If you insist, we can also write just the detected natural-id changes immediately, but surely not if session flushMode is set to flushmode < AUTO, because otherwise, as already mentioned above, we would break the long conversation patterns which base in no implicit flushes occuring until the last transaction.

>>So this use-case is foreign to me.

In-line natural-id mutation handling is of basic importance for all users applying the long conversation patterns.
The long conversation pattern should really not be a foreign use-case to you.
Also the concept of pre-fetching all interested entities into context with less as possible database-hits,
is suggested practice in hibernate documentation, so the use-case I have shown should not be that particular foreign.

Basically that what I want ask you and Eric is:

How should hibernate users applying the long conversation patterns (session.flushMode set to < AUTO) benefit from the new NaturalId feature? 
Currently the new apis are pretty useless in this context because transactional changes are not considered.

>>To be honest, I would never handle natural-id mutation in-line with other use-cases. Thats asking for trouble IMO. 

As the NaturalIdLoad feature is brand new, now we are still in time to define how it should work.
What are your concrete fears, in implementing a in-line natural-id mutation handling for all use-cases?
Finally all proposed enhancements are strictly concerning the NaturalId handling, nothing else, so all other stuff works as before:
I let run the matrix-tests today with the proposed changes and, except the tests regarding NaturalId which obviously have to be adapted, the rest ran witoud failures:
{code}
...
:hibernate-core:processMatrixResources UP-TO-DATE
:hibernate-core:matrixClasses
:hibernate-core:matrixUnitTest
Test org.hibernate.test.naturalid.immutableentity.ImmutableEntityNaturalIdTest FAILED
Test org.hibernate.test.naturalid.inheritance.InheritedNaturalIdTest FAILED
Test org.hibernate.test.naturalid.mutable.MutableNaturalIdTest FAILED
Test org.hibernate.test.naturalid.mutable.cached.CachedMutableNaturalIdTest FAILED
3037 tests completed, 5 failures
{code}

I understand that along classic flushing, in-line natural-id mutation handling would represent a complete new approach of synchronization process, 
but I think it is worth to be implemented and maintained.
Last but not least also users using flushmode AUTO would benefit from this new architecture in terms of performance, 
as hibernate gets saved from having to scan the entire persistence context for dirty-changes on each NaturalId load access.
I understand that you as project maintainer, are mainly concerned about hibernate being working correctly,
anyway I hope there are other hibernate-developers attributing some importance to performance aspects too.






      was (Author: pb00067):
    Hi Steve,
>>Another thing to keep in mind is that there is absolutely no need to perform the synch code in resolveNaturalId in cases where the natural id is immutable.

I'm already aware of this, just not noticed it yet here, because I tried to be as sintetic as possible and because also hibernate4.1.1 does call autoFlushIfRequired() in resolveNaturalId even if natural id is immutable,
so that's a particularity which has to do be fixed anyway.

>>Another issue here is that the proposed change is updating the second level cache very prematurely. Basically it is "bleeding" un-written and un-committed changes from the session into the second level cache for other sessions to see.

Other sessions do never pick up uncommitted changes from the second level cache (that would be a big issue indeed)!
-in the case you use 2L-Cache with transactional CacheConcurrencyStrategy for example Infinispan
  the other session always see last commited cache entry (InfiniSpan is a multi-version-capable cache for this purpose)
-in the case you use 2L-Cache with read-write CacheConcurrencyStrategy
  the cached entry gets locked until the end of the transaction so that other sessions don't pick up an uncommited value.
It is indeed true, that the proposed change is updating the second level cache rather early,
but as the user is more likely to commit rather than rollback his transaction finally, this should not be a problem.
Last but not least also a regular flush could occur already in the first phases of a transaction, with the identical effects, true or not?

>>You calculate the dirtiness and if dirty you update the natural-id xrefs but then just throw away the calculation. This is the concern I was addressing.

Sorry, but I cannot follow your argumentation: even if we would write just the natural-id changes to the database,
on every next flush that entity gets again checked for dirtiness anyway. Writing just the detected natural-id changes immediately to the database, don't saves hiberante from absolutely nothing in terms of total work amount IMO, in contrary:
you would split up the changes in more parts needing in total up to 2 update-executions instead to a single one.
If you insist, we can also write just the detected natural-id changes immediately, but surely not if session flushMode is set to flushmode < AUTO, because otherwise, as already mentioned above, we would break the long conversation patterns which trust in no implicit flushes occuring.

>>To be honest, I would never handle natural-id mutation in-line with other use-cases. Thats asking for trouble IMO. 
 As the NaturalIdLoad feature is brand new, now we are still in time to define how it should work.
 Which kind of troubles do you see concretely with a natural-id mutation in-line within other use-cases?
>>So this use-case is foreign to me.

In-line natural-id mutation handling is of basic importance for all users applying the long conversation patterns.
The long conversation pattern should really not be a foreign use-case to you.
Also the concept of pre-fetching all interested entities into context with less as possible database-hits,
is suggested practice in hibernate documentation, so the use-case I have shown should not be that particular foreign.

Basically that what I want ask you and Eric is:

How should hibernate users applying the long conversation patterns (session.flushMode set to < AUTO) benefit from the new NaturalId feature? 
Currently the new apis are pretty useless in this context because transactional changes are not considered.



  
> 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