ca.uhn.fhir.rest.server.exceptions.InternalErrorException: HTTP 500 : Failed to call access method: org.springframework.dao.DataIntegrityViolationException: could not execute batch; SQL [insert into HFJ_RES_TAG (PARTITION_DATE, PARTITION_ID, TAG_ID, RES_ID, RES_TYPE, PID) values (?, ?, ?, ?, ?, ?)]; constraint [fkbfcjbaftmiwr3rxkwsy23vneo]; nested exception is org.hibernate.exception.ConstraintViolationException: could not execute batch
The constraint listed is for:
alter table HFJ_RES_TAG
add constraint FKbfcjbaftmiwr3rxkwsy23vneo
foreign key (TAG_ID)
references HFJ_TAG_DEF (TAG_ID);
So it appears the other three threads failed - because the TAG_ID is not yet committed?
Following this test, a row for the profile will exist in HFJ_TAG_DEF, and a single row will exist in the HFJ_RES_TAG table for the one successfult thread.
If I run the test again, it will succeed for all 4 threads - every time. I can then reliably re-create the problem by manually deleting the HFJ_TAG_DEF (after first deleting the HFJ_HISTORY_TAG reference) and the related HFJ_RES_TAG rows.
The upshot of this is that the first time I run mass updates of a given resource (e.g. in a new environment), many threads will fail and I have to run everything again, sometimes several times as the error count decreases.
I guess I could run some sort of limited sub-set to try to seed the values, but I would prefer not to have to try to identify what this would be.
Would this be considered a bug, or just something I have to live with in my multi-threaded set-up?
--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/6ad97487-cd6f-469b-89dc-ee386ec51c6bn%40googlegroups.com.