When an entity is changed from being read-only to modifiable, its snapshot is created from its current state (in the session), not its persistent state (in the DB).
This can cause unexpected results when:
an entity had non-flushed changes when it was set to read-only, or
an entity's state (in the session) was changed after being made read-only.
If no other changes are made to the entity after being made modifiable, Hibernate will not detect that the entity is dirty, and those changes will not be pushed to the DB. If other changes are made, Hibernate will detect that the entity is dirty, and the newer changes will be persisted, but the older changes may not be.
I've added "FailureExected" tests that reproduce this issue:
A workaround to persist changes made to a read-only entity are:
// make the entity, dp, read-only
s.setReadOnly( dp, true );
// modify the read-only entity, possibly inadvertantly
dp.setDescription( "changed" );
// need to evict dp to keep it's modified state
s.evict( dp );
// add the modified entity to the session
s.update( dp );
// now dp is not read-only and its changes will be flushed
This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.
For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/
As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.