I don't think this specific issue can actually occur anymore with some of the work Steve did under
HHH-7689
where he enforces that a sqlException aborts the batch internally within the Batcher and it's also aborted when closing the connection.
The only time I still run into an issue is with a SavePoint implementation that really isn't supported but leaves the batch in a weird state when the addToBatch fails with something like a bean validation exception.
If you're morbidly curious you can mod the BatchingBatchFailureTest by changing the configure method to
@Override protected void configure(Configuration configuration) { super.configure( configuration ); configuration.setProperty( "javax.persistence.validation.mode", "AUTO" ); // explicitly enable batching configuration.setProperty( AvailableSettings.STATEMENT_BATCH_SIZE, "5" ); // and disable in-vm nullability checking (so we can force in-db not-null constraint violations) configuration.setProperty( AvailableSettings.CHECK_NULLABILITY, "false" ); }
to turn on the BeanValidation and then
@Column( nullable = true )
@NotBlank
public String getName() {
return name;
}
on the entity in order to trip an exception other than a SQLException from the addToBatch.
Either way, I think I'm ok with closing this specific issue based on what was done under
HHH-7689
and I have a valid workaround for my grey area SavePoint case.
|