Tuesday, July 05, 2005

How to write a Java Object to a database blob column

This snippet describes how to write a Java Object to a database BLOB column, then read it back. The Java Object must be Serializable so that it can be represented as a byte array for either writing or reading.

First, writing to a blob column. For this example, there is a table called blobtable. It contains a BLOB colunm called blobcolumn. The way to write it to the DB is to assign the Serializable to a byte array, then write that byte array to the DB.


public void saveObjectToBlob(
        Connection conn,
        Serializable saveObject)
throws IOException, SQLException {

    PreparedStatement stmt = null;
    String query =
        "INSERT " +
        "INTO blobtable (" +
        " blobcolumn) VALUES (" +
        " ?) ";

    stmt = conn.prepareStatement(query);

    // write the object content to a byte array
    ByteArrayOutputStream bos = new ByteArrayOutputStream();
    ObjectOutputStream oos = new ObjectOutputStream(bos);
    oos.writeObject(saveObject);
    oos.close();
    byte saveObjectBy[] = bos.toByteArray();
    stmt.setBytes(1, saveObjectBy);
    // Oracle converts it to BLOB automatically

    stmt.executeUpdate();
}


After writing it to the blob column, you can read it back. The way to read it back is to use the Blob interface for the DB blob column. Read it back as byte array, then cast that to Serializable. Then cast the Serializable to the original Object type.


public Serializable readObjectFromBlob(Connection conn)
throws SQLException, IOException, ClassNotFoundException {

PreparedStatement pstmt = null;
ResultSet rset = null;
String query =
"SELECT " +
" blobcolumn " +
"FROM " +
" blobtable ";

pstmt = conn.prepareStatement(query);
rset = pstmt.executeQuery();
Serializable result = null;
if (rset.next()) {
byte blobcolumnBy[];
Blob bl = rset.getBlob(1);
blobcolumnBy = bl.getBytes(1, (int) bl.length());

ByteArrayInputStream bis =
new ByteArrayInputStream(blobcolumnBy);
ObjectInputStream ois = new ObjectInputStream(bis);
Object obj = ois.readObject();
ois.close();
result = (Serializable) obj;
}

return result;
}

Monday, July 04, 2005

Brown, J2EE, tractor trailer

I recently was working on an application that was Servlet based in Tomcat. That was pretty good. It was nice to be able to roam around the Java language and libraries and do stuff with threads and such.

Before this most of my Java experience was EJB. I don't really like EJB. It seems annoying a lot of the time with its rules and restrictions. And it's so verbose and so much overhead getting things deployed and callable. We've had some success using XDoclet to auto-generate some of the verbiage, but it's still big. We're not even using entity beans, thankfully; that would be just so much more overheads.

We have to be quick to get things done on aggressive schedules and be able to modify existing systems for new requirements. Sometimes with J2EE it seems like we're a courier trying to deliver packages in the downtown business district using a tractor trailer. The big rig is scalable; you can load all kinds of heavy freight on it, but in the downtown during the daytime it is so bulky that it has trouble navigating the traffic, changing direction or parking. For the traffic congested downtown you'd be better with one of the UPS brown vans, which carry a big enough load, but can move around better in thick traffic and tight parking and can change direction easily based on how business unfolds that day.

Now if you're moving say 40 brand new large sofas from a warehouse in Montreal to a furniture store in Sydney then the tractor trailer is the best vehicle to use. You can fit them all in one load, and the rig manages the long highway miles easily.

Looking at it that way, it makes me sometimes get down a bit on J2EE. But thinking about it more, I think my gripe is more with EJB than with the full J2EE. After all I know I like the Servlets stuff. EJB just seems to suck up the joy of programming at times.

I know I'm not the only one who isn't excited about EJB. When people write entire books about J2EE without EJB then there are many others too who want to use J2EE but are turned off by EJB. Still with J2EE, especially EJB the specs are just eye glazing. Even a book like the 21 days that tries hard to be accessible and reader friendly is painful to read when they necessarily delve into the J2EE specs and rules. I wish the concepts and terminology could be somehow simplified.

I always thought that EJB was a necessary evil to obtain scalability. Turns out that's not so. walmart.com was built using just Apache and Tomcat servlets. Apparently no need for EJB to achieve performance, security, etc. I find that very interesting.

So if we don't need it to get scalability then maybe we'd be better off without EJB. Just use servlet - which I've found well thought through and agreeable to work with - plus a much more lightweight framework, or maybe no real extra framework. That idea appeals to me. I'll get to work with Tomcat and servlet for a bit longer on this project, I'm not real excited about going back to EJB.