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
{code}
@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" );
}
{code}
to turn on the BeanValidation and then
{code}
@Column( nullable = true )
@NotBlank
public String getName() {
return name;
}
{code}
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.
|
