Foreing key constraint violation when updating dependant entity

Entity operations performed result in the following sequence of SQL statements being executed by Hibernate (according to the logs for org.hibernate.SQL and org.hibernate.type.descriptor.sql):

insert into fileContent (filename, originalFilename, id) values (<filenameA>, <originalFilenameA>, 15537);
insert into fileContent (filename, originalFilename, id) values (<filenameB>, <originalFilenameB>, 15538);
insert into fileContent (filename, originalFilename, id) values (<filenameC>, <originalFilenameC>, 15539);
update project set filea_id=15537, fileb_id=15538, filec_id=15539 where id=<projectId>;

The insert statements are executed without any errors.However, when committing the transaction, the update operation fails with an SQL exception:

org.hibernate.engine.jdbc.spi.SqlExceptionHelper[142] - ERROR: insert or update on table "project" violates foreign key constraint "fk__filea_id__filecontent"
  Detail: Key (filea_id)=(15537) is not present in table "filecontent".
  • PostgreSQL 14
  • Postgresql JDBC 42.3.8
  • Java OpenJDK 17
  • Hibernate 5.6.14.Final

Anyone any idea, why this is happening? Am I missing something?

Maybe the fileContent with id 15537 was deleted after the insert? Are the inserts and updates running in the same transaction?

No, the object has definitely not been deleted. And, yes, all operations are within the same transaction.

However, there is one change being performed to the FileContent instances after saving them and before committing the transaction: Based on Spring Security, an Access Control List (ACL) with corresponding Access Control Entries (ACE) is created for each of the FileContent instance.

Meanwhile, I found out that the exception does not occur if I comment out the ACL/ACE creation. But I still do not understand why this is the case. The ACL/ACE creation neither does a select for the FileContent instance nor does it update the FileContent instance.

One more info: FileContent entities and ACLs/ACEs entities are stored in different schema within the same database.

No idea about Spring Security, so better ask in Spring forums about that.