Hibernate ‘on-delete=cascade’ Performance Tuning

Be careful when you use Hibernate’s support for database ON DELETE CASCADE constraint. If not configured properly, your application might be more performance-costly than you think.

Let me use the example from Gavin King’s email introducing the new setting of on-delete=”cascade”:

<set name="children" inverse="true" cascade="all">
  <key name="PARENT_ID" on-delete="cascade">
  <one -to-many class="Child">
<set>

For a parent object associated with N child objects (cascade=”all”), the setting on-delete=”cascade” avoids issuing N deletes to the database if the parent were to be deleted.

Detecting Infinite Loop

Just yesterday I have come across a problem at work. The problem is the possible occurrence of infinite loop inside a tree structure. To solve it, I need to come up with an algorithm to detect infinite loop occurrence. This little puzzle brings back the memory of a similar and simpler puzzle my high school computer science instructor asked the class.

The problem was: Given an uni-directional linked list, detect infinite loop without using any extra data structure.

Spring Bean Substitution

If we ever try to import a spring configuration from a packaged jar and need to customize some of the bean definitions, we would find ourselves having to do these things:

1. extract the packaged configuration to somewhere we can actually edit;
2. change the bean definition according to our needs;
3. import the new configuration and exclude the original one.

Even though this works just fine, we will have to maintain the configuration copy and synchronize it with any updates made to the original one. This feels like forking our own branch from the spring configuration.

I think spring configuration can be a lot more flexible and powerful if we can substitute beans instead of having to redefine the whole bean dependency tree. Currently spring provides no such mechanism, so I tried a little hack utilizing the BeanFactoryPostProcessor and the BeanPostProcessor.