[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-6689) DefaultMergeEventListener changes CheckNullability flag - not thread save

[Piotr Findeisen (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44191#comment-44191 ] 

Piotr Findeisen commented on HHH-6689:
--------------------------------------

Steps to reproduce should be as follow:

 # take an entity class {{E}} with non-null field
 # set {{checkNullability}} to false
 # If you now execute {{merge}} on new instance of {{E}}, you shall not receive {{PropertyValueException}}. If you have additional validation defined for entity {{E}}, you could receive {{javax.validation.ConstraintViolationException}} instead
 # Repeat step no. 3 in two threads several times. In {{DefaultMergeEventListener.mergeTransientEntity}} {{PropertyValueException}} is caught and handled this way: {code}if ( isNullabilityCheckedGlobal( source ) ) {
	throw ex;
}
else {
	// retry save w/o checking for non-nullable properties
	// (the failure will be detected later)
	saveTransientEntity( copy, entityName, requestedId, source, copyCache, false );
}{code} Because {{isNullabilityCheckedGlobal}} is affected by by the other thread, it can, incorrectly return {{true}}.

> DefaultMergeEventListener changes CheckNullability flag - not thread save
> -------------------------------------------------------------------------
>
>                 Key: HHH-6689
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6689
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 3.6.5
>         Environment: Websphere Application Server 7.0,  DB2,  Windows Server, Hibernate 3.6.5
>            Reporter: John SMith
>              Labels: hibernate
>
> saveTransientEntity() method saves the CheckNullability setting,  changes it using the getFactory().getSettings().setCheckNullability  method, and does save processing.   After save processing, the saved value is restored.
> During load testing, we have had situations where the CheckNullability becomes set to TRUE and causes failures because of null checks.
> It has been difficult to debug, but it appears that this is not thread safe - multiple threads accessing this method can change the value of this setting.
> It can also be that a database error can cause an exception that will cause the checkNullability flan not to be reset.

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