I believe I have found something that can perhaps shed more light. When comparing the similar code that does work I observed that the code that works uses

@Id
@Column(name = PROP_ID, unique = true, nullable = false)
@GeneratedValue(generator = DEPLOYMENT_SEQ, strategy = GenerationType.SEQUENCE)
@SequenceGenerator(name = DEPLOYMENT_SEQ, sequenceName = DEPLOYMENT_SEQ, allocationSize = 1, initialValue = 1)

whereas the code that fails uses

@Override
@Id
@Column(name = PROP_ID, unique = true, nullable = false)
@GeneratedValue(strategy = GenerationType.IDENTITY)

in other words, the code that works uses SEQUENCE ID generation strategy whereas the code that fails uses an IDENTITY one. Therefore, out of curiosity I replaced the generation strategy for the code that fails with a SEQUENCE one as well and behold - it started working again. By examining the Hibernate logs I noticed a difference in the code's behavior between the 2 strategies:

16:57:55,941 INFO  [stdout] DEBUG [default task-2        ] [org.hibernate.SQL             ] 
16:57:55,941 INFO  [stdout]     select
16:57:55,941 INFO  [stdout]         currval('data_source_resources_id_seq')

08:33:08,874 INFO  [stdout] (AsyncAppender-Worker-STDOUT) DEBUG [default task-2        ] [org.hibernate.SQL             ] 
08:33:08,874 INFO  [stdout] (AsyncAppender-Worker-STDOUT)     select
08:33:08,874 INFO  [stdout] (AsyncAppender-Worker-STDOUT)         nextval ('SETTING_RESOURCE_SEQ')

It is immediately noticeable that the IDENTITY strategy uses

SELECT currval(...)

whereas the SEQUENCE one uses

SELECT nextval(...)

. This seems the correct behavior since the IDENTITY strategy first inserts and the queries for the assigned value whereas the SEQUENCE one first increments the sequence and then uses it for both INSERT statements. A quick examination of the Hibernate bindings logs reveals correct behavior in both cases - which does not explain why SEQUENCE works but IDENTITY does not. Perhaps it is some kind of PostgreSQL issue since the way IDENTITY strategy is actually implemented is via a BIGSERIAL and the JOIN is on a primary key, so perhaps some strange issue with using a BIGSERIAL as a referenced FOREIGN KEY in the JOIN-ing entity's table.

Any ideas how to explore this further ... ?