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.

Gavin also tells us that this setting only optimizes away the delete statements while all semantics are preserved. Well, what exactly does he mean?

I will roughly explain the procedure Hibernate performs to cascade delete in the simplest scenario:

1. mark entity for deletion
2. iterate through all of entity’s associations having cascade delete (one or many)
3. if the association is single, perform delete on this association (by starting step 1 for this association)
4. if the association is many, perform delete on this collection by:
   1. iterate all the collection elements, loading them from the database if necessary
   2. for each collection element, perform delete on the element (by starting step1 for this element)
5. if not on-delete=”cascade”, issue delete statement on this entity

When you have a to-many association with cascade=”all” as described in our example, Hibernate iterates the associated collection having size N, loading them from database if necessary, and marks each collection element for deletion. Before actually issuing delete statements for these elements, Hibernate searches for any other cascades configured on them and perform these found cascading actions accordingly.

Even with the setting on-delete=”cascade” on a specific lazy collection, cascade=”all” causes Hibernate to initialize and iterate the collection (because it wants to check if the elements in this collection also cascade delete to other associations). Therefore, when you are sure there are no other cascading actions configured on your child entity (the element in the on-delete=”cascade” collection), use the setting cascade=”save-update” instead of cascade=”all” to prevent Hibernate from performing the delete cascade checks and consequently avoid loading your lazy to-many association into memory.

If you have multiple layers of delete cascade, from parent to children and from child to grand children, consider the size of your collections and decide if you want to set up multiple layers of ON DELETE CASCADE constraints in database accordingly or preserve the configuration of cascade=”all” and on-delete=”cascade” to let Hibernate handle the delete cascade on the grand children.

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

The linked list data structure is really simple:
Node.java

class Node {
  Node next;
}

My solution to the problem was something like:
Function isInInfiniteLoop

boolean isInInfiniteLoop(Node node) {
  if (node == null) {
    return false;
  }
  Node turtle = node; // slower moving node
  Node rabbit = node.next; // faster moving node
  while (rabbit != null) {
    if (rabbit.equals(turtle)) {
      // the faster moving node has caught up with the slower moving node
      return true;
    } else if (rabbit.next == null) {
      // reached the end of list
      return false;
    } else {
      turtle = turtle.next;
      rabbit = rabbit.next.next;
    }
  }
  // rabbit reached the end
  return false;
}

Simple, isn’t it! At the first glance, almost everyone wondered if this short piece of code is really up to the task. The logic behind it is analogous to having two runners, one (rabbit) running faster than the other (turtle) and, if the course is circular, the faster runner eventually overlapping the slower runner.

Note that it is important for the slower runner to keep moving instead of remaining at the same node because we don’t know where the course will merge into circle. If the merge point is further down the course, the non-moving runner will never enter the loop which the faster runner is lapping.

This algorithm is not only simplistic, it is also efficient. It is just a O(N) or linear function.

Now, getting back to my work related problem, the data structure I am facing is a tree instead of a sequential linked list. The structure is something like:
TreeNode.java

class TreeNode {
  TreeNode parent;
  List children;
}

I have had a hard time figuring out how to apply my little rabbit and turtle algorithm into this context. When it comes to tree structure, I always think recursion. However, I cannot imagine transforming my algorithm into a recursive algorithm. It just appears overwhelming.

Then, it suddenly hits me, since TreeNode can traverse to its parent, luckily, I could do it backwards. The traversal from child to parent is just another sequential linked list.

It simply feels awesome to see that this little algorithm I thought of years ago is still useful today.

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.

The idea comprises three parts:

• BeanSubstitutionMapping
  • Users define which bean to be substituted and which bean is substituting.
• BeanSubstitutionConfigurer implements BeanFactoryPostProcessor
  • When spring application context is created, it reads the substitution mappings and store them.
• BeanSubstitutionProcessor implements BeanPostProcessor
  • Everytime a bean is requested, it reads the substitution mappings, checks if the bean to be loaded has been defined for substitution.
  • If the bean to be loaded has been mapped for substitution, it returns the substituting bean defined in the mapping instead.

Here is the difference when we use bean substitution:

1. don’t need to extract the original packaged configuration;
2. don’t need to exclude the original configuration;
3. define our substituting bean;
4. define the substitution mapping;
5. no longer need to maintain and synchronize with jar updates, only need to maintain our own configuration.

I ran a simple test case described below. I was trying to substitute the “helloWorld” bean with “helloWorld2” bean.

In real world scenario, the bean definition for “helloWorld”, java class for HelloWorld, and HelloTaipei would be packaged in jar where we can only read but not modify. The bean definitions for “helloWorld2”, “config”, “mapping”, and java class HelloIrvine would be defined in our project where we are able to modify.

HelloWorld.java

public interface HelloWorld {
  public String print();
}

HelloTaipei.java

public class HelloTaipei implements HelloWorld {
  public String print() {
    return "Hello Taipei!";
  }
}

HelloIrvine.java

public class HelloIrvine implements HelloWorld {
  public String print() {
    return "Hello Irvine!";
  }
}

applicationContext.xml

<beans>
  <bean id="config" class="my.sandbox.beans.factory.config.BeanSubstitutionConfigurer"/>
  <bean id="helloWorld" class="my.sandbox.substitution.HelloTaipei"/>
  <bean id="helloWorld2" class="my.sandbox.substitution.HelloIrvine"/>
  <bean id="mapping" class="my.sandbox.beans.factory.config.BeanSubstitutionMapping">
<property name="targetBean" value="helloWorld"/>
<property name="sourceBean" value="helloWorld2"/>
  </bean>
</beans>

BeanSubstitutionTest.java

public class BeanSubstitutionTest extends
AbstractDependencyInjectionSpringContextTests {
  private HelloWorld helloWorld;
  public BeanSubstitutionTest() {
    setAutowireMode(AUTOWIRE_BY_NAME);
  }
  @Override
  protected String[] getConfigLocations() {
    return new String[] {
      "classpath*:META-INF/applicationContext.xml"
    };
  }
  public void testHelloWorld() {
    System.out.print(helloWorld.print());
  }
  ...
}

The BeanSubstitutionTest ran successfully and printed out “Hello Irvine!” instead of “Hello Taipei!”.

Note that even though BeanSubstitutionProcessor returns the substitution source bean instead of the substitution target bean, the target bean is already created by the application context when BeanSubstitutionProcessor kicks in. This means that we have an unused instance of the target bean in the application context.