TimShadel.com

We’ve been grappling with a number of different problems with our app over the last week. We’ve made many improvements, including several changes to our Spring configs (which I may touch on another day), but we still had a problem where occasionally we ran out of database connections momentarily — no matter how many we had in the pool to start with.

So the other morning I got an itch to start coding while I was waiting for my carpool ride to show up. By the time I got to work, I had a rough draft of something I wanted to try out. It’s a simple logging DataSource. We converted our datasource to one driven by Spring a couple months ago, but we still have a combination of straight JDBC, an old custom in-house ORM tool, and Hibernate. Somewhere among them, we’ve got something occasionally misbehaving.

It’s a pretty simple concept. I decided to extend Spring’s DelegatingDatasourceProxy to make my LoggingDataSource. Configuration is just as simple as changing this:

<jee:jndi-lookup id="dataSourceTarget" jndi-name="java:/MyJbossDS"/>

to this:

<bean id="dataSource" class="com.timshadel.util.LoggingDataSource">
    <property name="targetDataSource" ref="dataSourceTarget"/>
    <property name="filterPattern" value="^(com.timshadel|com.example).*"/>
</bean>

<jee:jndi-lookup id="dataSourceTarget" jndi-name="java:/MyJbossDS"/>

When you turn it on, you might see something like this:

[main] INFO  com.timshadel.util.LoggingDataSource  - Connection request stack trace, filtered by '^(com.timshadel|com.example).*'
        com.example.myapp.model.MyClass.determineSomethingImportant(MyClass.java:770)
        com.example.myapp.model.MyClass.updateStatusString(MyClass.java:674)
        com.example.myapp.model.MyClass.loadStatusInfo(MyClass.java:643)
        com.example.myapp.model.MyClass.reloadStatusInfo(MyClass.java:332)
        com.example.myapp.util.helper.LegacyHelper.run(LegacyHelper.java:440)
[main] ERROR com.timshadel.util.LoggingDataSource  - Connection request stack trace, filtered by '^(com.timshadel|com.example).*'
        CAUGHT EXCEPTION (java.sql.SQLException): Pretend there's no more connections.
        com.example.myapp.model.MyClass.determineSomethingImportant(MyClass.java:770)
        com.example.myapp.model.MyClass.updateStatusString(MyClass.java:674)
        com.example.myapp.model.MyClass.loadStatusInfo(MyClass.java:643)
        com.example.myapp.model.MyClass.reloadStatusInfo(MyClass.java:332)
        com.example.myapp.util.helper.LegacyHelper.run(LegacyHelper.java:440)

All of the stacktrace lines have been removed except those that match your pattern. This is helpful to make sure you cut through a typical enterprise Java call stack to only show the calls your code is making. For us that was helpful as a poor man’s way to determine which pieces of our code were using connections frequently. One simple run turned up a few hotspots. If we need to dig in a bit more, perhaps we’ll throw together a simple Ruby script to count how often a given call stack shows up in the log.

Also note, that since this puts the info out to Log4j, you can obviously pull this logging out to a completely separate file, set a different threshold, or use any of the other standard Log4j features to capture this information in a way that’s useful to you.

Finally, please remember that I pulled lots of this together while riding to work. It’s not really meant to be used for anything serious. Please expect warts and problems, but hopefully it’s enough to help get you goin’.

It’s hard to believe that it’s been a year since my “burrito” podcasts on JSF. So what have I done in this last year with JSF? What is my opinion now and how has it changed?

Have you ever skipped out on a movie that was popular? Decided not to see it because it either didn’t fit your taste or didn’t mesh with your life in some other way? I have. I usually look back later on without regret. That’s the way I feel looking back at JSF a year later, but let give you some details.

Read more…

I got the following question from a friend the other day.

I have a parent and a child object with a one-to-many relationship by the child’s table having a column that points to it’s parent. What are the correct settings for the mapping in this situation where I need to be able to remove children from the parent’s set, and save the updated parent. It seems like I’ve been through all sorts of combinations, and I was wondering if you could lend me your advice.

The same day I also had a similar question from a colleague at work. I figured I’d post my response here so I could easily find it in the future. I’ve tried to make the code reasonably generic, but watch out for dumb typos.

You should setup the parent mapping like this:

<set name="children" lazy="true" inverse="true">
  <key column="PARENT_ID"/>
  <one-to-many class="my.child.ChildClass"/>
</set>

And then map the child like this:

<many-to-one name="parent" column="PARENT_ID" not-null="false" class="my.parent.ParentClass"/>

Notice that the column name in each refers to THE SAME COLUMN. You’re just connecting the link.

From the parent class:

/** The set of children of this object. */
private Set<ChildClass> children = new HashSet<ChildClass>();
private void setChildren(Set<ChildClass> children) {
    this.children = children;
}

public void removeChild(ChildClass child) {
    children.remove(child);
    child.setParent(null);
}

public void addChild(ChildClass child) throws IllegalArgumentException {
    if (child == null) {
        throw new IllegalArgumentException("Child may not be null");
    }
    if (child.getParent() != null) {
        child.getParent().removeChild(child);
    }
    child.setParent(this);
    children.add(child);
}

From the child class:

/** The parent. */
private ParentClass parent;

This simple example seems to illustrate the basics. My friend later pointed out that one of the things tripping him up was the cascade option. Recognizing that it’s completely separate from the inverse property was a big step. That’s an important point – the inverse just means that the child objects have a property that refers back to the parent. It helps resolve object relationships on load, but the cascade and lazy attributes tell Hibernate when to save and load the objects to and from the database.

You’ve got database code that uses both Hibernate and Spring. You need to test it. In this podcast I talk about how you can use DBUnit and HSQLDB along with some Spring test classes to create a setup that will let you test database code fast, and in isolation. Just what good unit tests should do.

Check out some great references on database testing, including the ones I mentioned in this show.

DBUnit and thier best practices for database testing.
The HSQLDB home page.
Scott Ambler’s excellent discussion of database refactoring.
An article from TheServerSide.com about unit testing with HSQLDB.
Spring’s AbstractTransactionalDataSourceSpringContextTests class that helps make some of your database testing easier. Check the other classes in the hierarchy for specifics on what they do as well.

I decided to try out adding a GarageBand.com song today, like the SlashdotReview podcast does. The song is Calendar by Eugenia and The Boys. Let me know if you like it. Also feel free to revolt and tell me to pull the music and keep it to tech stuff.

Listen now with the Flash player.

Download Unit Testing Database Code.

Listen now with the Flash player.

Download Key Hibernate Features.

This show wraps up the intro to Hibernate with a discussion of some of its key features including directly using POJOs, detaching objects from a Session, lazy loading, using Hibernate’s “user types” to map custom objects to column values, and its support for mapping class hierarchies. It’s a long one today – 26 minutes – but a bit more focused. Enjoy.

Listen now with the Flash player.

Download Why You Need Hibernate.

Show Notes

This week’s on ORM in Java, and I’ll focus on Hibernate. Today is all about why you need a persistence framework, and a quick intro to Hibernate and why you need it now.

Handcoded time: 9 min
Hibernate time: 103 sec

That’s the time we saved on an internal operation by switching it from hand-coded JDBC to Hibernate. These measurements tell a bigger story than SQL, though. They really tell about how Hibernate makes it easy to write understandable, fast code.

Let me back up. This application retrieved thousands of database rows and processed them. Part of the processing was to take a column containing XML data, grab the XSL transform from another table, and store the result to the file system. A bit messy. The orginal programmer used JDBC code and a database view to get the needed information to accomplish his task. When the test database had 120K+ rows, the performance problem became obvious. Another of our programmers worked with him to make it use Hibernate. Not only did we get a more understandable object model, we got great caching, relationship managment, and tuned SQL for free.

Bottom line: Hibernate encourages understandable object models, and makes it really fast to use them well.

Not only has Hibernate released a new stable version, but I really like the way their “Recent Site Upddates” table looks. It’s all tables and CSS, using mouse events to change the row colors. It’s compact, and pretty. I like it.