hibernate.jdbc.batch_size set to 50 not allowing to test single update during exception

I needed to fix security vulnerability stating exception contains sensitive details whenever application is unable to update data in DB and i have fixed it by catching the db exception and customizing its error message.

To test this fix, i need to execute updateList service and validate the response but in Hibernate hibernate.jdbc.batch_size is set to 50 due to which single update cannot be tested as this would always return data updated successfully because update query will hit the database only when update count reaches to 50.

I can only test the fix if by putting sessionFactory.getCurrentSession().flush() as mentioned below.

public void update(final List list)


Is there any other best solution? or flush() will force query or queries to get updated in the DB but not sure about the impact on hibernate.jdbc.batch_size = 50;

“update query will hit the database only when update count reaches to 50” it is not completely true. Also it will hit db when transaction is closed.

You can add flush, but it may lead to performance degradation (hibernate.jdbc.batch_size=50 was there for reason).

I suggest you to put you try catch in some other place. Like if it is servlet add custom filter. It will also save you from such exception in different place. With Hibernate it is hard to predict when it decide to flush data to db.

Is there any other best solution?

To handle a single error case, you should not change your implementation in a way that will not reflect the real implementation in production.
Why ? Because after this test you have to think to make your implementation step back to have the expected behavior in production.
You have not to forget to do these changes at each time you want to test this special case.
Otherwise your application may not work any longer as expected.
It is not the good way.

To test your case, you could write an unit test.
Besides, this one should not necessarily rely on real database calls.

I propose this approach to unit test :

  1. Mock the object that produces the exception with sensitive information in the message.
  2. Record a behavior for it. When it is called, do this mock object throws an exception with similar sensitive information in the message.
  3. When the method to test is invoked, assert the error message get doesn’t contain any sensitive information.

If this feature is really important to be tested regularly and in an environment very close from the target, you could create an integration test that uses the same constraints that the application in production (hibernate.jdbc.batch_size=50) and that so insert also at least 50 data in a database.

Of course, this test may be costly in terms of time and should be invoked automatically only on a CI tool.