Your Catchphrase Here! » Tech

Trapped DVD after a failed Snow Leopard Install on a Mac Mini

Christopher — Wed, 02 Dec 2009 15:31:38 +0000

Yeah, that’s a long title, but I want it to be easily searchable on the web.

I have an Intel-based Mac Mini running Mac OS X Tiger. I recently procured a Snow Leopard DVD and read that you can, in fact, upgrade from Tiger to Snow Leopard. Snow Leopard has some cool new features that I thought I’d like, so I gave it a shot.

I inserted the DVD and the finder window came up showing me the “Install Mac OS X” option and I double-clicked on it. It told me it had to reboot in order to perform the installation, so I said okay and it rebooted.

(Note that I didn’t care what happened to my existing installation, files, etc… this machine is used for web application testing, so I don’t care if I wipe everything or not).

After a few minutes, the installer came up and asked me what language I wanted to use (English) and I continued the install. It thought about things for a while and then told me:

Mac OS X cannot be installed on this machine because it does not have enough memory.

My options at this point were: Restore from Backup and Reboot. I chose the latter, thinking that the DVD would eject and I’d be back to using my old Tiger install.

Instead, the DVD stayed in the drive and, after the reboot, the whole process repeated — basically, I was asked what language I wanted and then told that my computer didn’t have enough memory to install Snow Leopard. :(

So, I tried the most obvious thing any Mac user would do: I pressed the eject button on the keyboard. No dice. I held the eject button down for what must have been 2 minutes. Nothing.

I tried Googling for answers. Lots of people giving various suggestions, none of which was working for me. CTRL-COMMAND-O-F apparently doesn’t work on Intel Macs. Holding OPTION during boot did nothing. Holding EJECT did nothing. Holding the mouse button down did nothing. I was seriously contemplating cracking open the machine to extract the DVD.

Someone suggested plugging the mouse button directly into the Mac, because some USB hubs don’t work quite right at initial boot. I have a Mac keyboard with my mouse plugged directly into that. That’s about as directly-plugged as you can get, right?

Well, apparently not. I moved by USB mouse from the keyboard to the back of the Mac Mini and held down the mouse during boot. Voile! Out popped the DVD.

So, anyone having similar problems can try this trick. It may save you from tearing-open your Mac Mini, or tearing-out your hair.

Properly Handling Pooled JDBC Connections

Christopher — Mon, 16 Mar 2009 22:46:44 +0000

I’m an active member of the Tomcat-users mailing list and I see lots of folks that post questions about not being able to get a new database connection. The answer is simple: you have exhausted their JDBC connection pool. The answer is not so simple because the reasons for the situation can often be different, but most likely, your application is not properly handing pooled connections. Read on for information on how to code your app to properly handle such pooled connections.

I won’t go on and on about what a good idea connection pools are. That is either self-evident or covered elsewhere. What is not properly covered elsewhere is how to write your code correctly. They’re all throwaway examples that work under the best circumstances but fall apart when anything goes wrong.

When using a pooled connection, the idea is that you shouldn’t have to go out of your way to treat it specially. Technically, the techniques shown in this post are not just useful for pooled connections: it’s simply how you should code JDBC interactions, pooled or otherwise. The basics are simply: acquire your connection, and make sure you close everything before your method completes. Unfortunately, folks often forget that exceptions can be thrown and your cleanup code might not actually get called.

Below are two annotated code samples that should demonstrate everything you should be doing when handling JDBC connections. I hope this helps some folks out there.

The first code snippet is for when you are not engaging in a SQL transaction. Sure, you could use the transactional code in all cases, but the non-transactional one is simpler and will make your code easier to read and understand. It also won’t give you any “cannot rollback connection that isn’t in a transaction” errors. My code throws application-specific exceptions to demonstrate how to shield calling code from the “complexities” of JDBC.

// It's important that these references are /outside/ the try/catch
// and that they are set to null. The compiler will enforce this; I'm
// just being explicit.
Connection conn = null;
PreparedStatement ps = null; // I prefer PreparedStatements; use Statement if you want
ResultSet rs = null;

try
{
    conn = ...; // Get your connection however you want

    // Issue your queries and get your results.
    // Remember: if you want to issue multiple queries and/or
    // work with multiple result sets, either declare more Statement
    // and ResultSet locals above and duplicate all cleanup logic for them,
    // or make sure you close each object along the way before you
    // try to re-use the reference.

}
catch (SQLException sqle)
{
    // NEVER swallow exceptions. At least log them using "sql.printStackTrace()"

    // Note that the root exception is being passed-along to the
    // application-specific exception. This allows error messages to include
    // the /full/ stack trace.
    throw new ApplicationException("Error in database code", sqle);
}
finally
{
    // Anyone who has done any real work in Java will know that a 'finally'
    // block will be run after the 'try' block regardless of any exception
    // activity.

    // A couple of things to note, here:
    //   1. Close objects in the proper order: result, then statement,
    //      then connection.
    //   2. Each close gets its own try/catch block. You don't want
    //      the connection to be leaked just because the result set
    //      failed to close properly.
    //   3. Don't throw any exceptions in a finally block. If there is
    //      already an exception "in the air", you'll shoot it down
    //      and replace it with a new one. The original exception is
    //      almost certainly more useful.
    //   4. NEVER swallow an exception. At least log the error.
    //   5. This cleanup code has whitespace removed for brevity.
    //   6. This cleanup code lends itself to being put into a separate
    //      method. I usually have a 'close' method that takes 3 arguments:
    //      Connection, Statement, ResultSet and does the same thing.

    if(null != rs) try { rs.close(); } catch (SQLException sqle)
        {  sqle.printStackTrace(); }
    if(null != ps) try { ps.close(); } catch (SQLException sqle)
        {  sqle.printStackTrace(); }
    if(null != conn) try { conn.close(); } catch (SQLException sqle)
        {  sqle.printStackTrace(); }
}

That’s it. Not really that hard, but if you don’t have your try/catch block straight and the proper code in the finally block, they you are asking to leak connections or other stuff. Java might protect you from a lot of things by collecting its own garbage, but you can still bring down your database server by opening way too many connections and then leaking them all.

Transactions bring another problem to the table because you have to do a rollback unless you want the transaction to commit. Most connection pools default to “auto-commit” mode, and the JDBC spec states that calling setAutoCommit(true) commits a transaction if one was in progress. That means that you need to ensure that your transaction is rolled-back… otherwise it will be committed for you, and that’s probably not what you want.

Connection conn = null;
PreparedStatement ps = null;
ResultSet rs = null;

try
{
    conn = ...; // Get your connection however you want
    conn.setAutoCommit(false); // BEGIN

    // Issue your queries and get your results.

    conn.commit();             // COMMIT
}
catch (SQLException sqle)
{
    // DO NOT allow the call to rollback to throw an exception. See the
    // notes in the 'finally' block in the last example. You could even
    // create your own 'rollback' method to simply do this to clean-up
    // your code a bit.
    if(null != conn) try { conn.rollback(); } catch (SQLException sqle1)
        { sqle1.printStackTrace(); }

    throw new ApplicationException("Error in database code", sqle);
}
catch (ApplicationException ae)
{
    // Yes, catch ApplicationException. Anything that the current method can
    // throw /must/ be caught and re-thrown.

    if(null != conn) try { conn.rollback(); } catch (SQLException sqle)
        { sqle.printStackTrace(); }

    throw ae; // Re-throw the same exception
}
catch (RuntimeException rte)
{
    // You wouldn't want a NullPointerException to end up committing your
    // partial transaction, would you?

    if(null != conn) try { conn.rollback(); } catch (SQLException sqle)
        { sqle.printStackTrace(); }

    throw rte; // Re-throw the same exception
}
catch (Error e)
{
    // Errors, too!

    if(null != conn) try { conn.rollback(); } catch (SQLException sqle)
        { sqle.printStackTrace(); }

    throw e; // Re-throw the same error
}
finally
{
    // Here, I'm taking my own advice to put the cleanup code into a
    // separate method. See how nice this looks?
    this.close(conn, ps, rs);
}

Following the code samples above will keep your DBAs very happy, and you’ll never have post a message to a mailing list and have to admit that you really didn’t know what you were doing when it comes to JDBC programming.

I have a few more general tips for JDBC, connection pools, etc.:

In development, set your connection pool to a fixed size of 1 connection. This will let you know immediately if you have any deadlock potential in your code when trying to request more than one connection at a time from the pool. If you do request more than one connection at a time, then there is a possibility that you could deadlock your application waiting on database connections. Just do it. It won’t hurt, and you might be surprised to find out that you forgot to ‘close’ a connection (and therefore return it to the pool). Using this technique will find the error much faster than others.
Use a “validation query”. When you request a connection from the pool, you can have the pool validate that the connection is still valid (i.e. connected, etc.) by issuing a simple query to the database. Make this a simple query. Queries like “SELECT * FROM purchase” are bad ideas. Choose something like “SELECT 1 FROM DUAL” (for you Oracle folks) or “SELECT 1″ for databases that don’t require a table name for trivial SELECT queries. If you’re using MySQL, use “/* ping */ SELECT 1″ since recent versions of Connector/J can detect the “/* ping */” part of the query and issue a super-cheap connection test that doesn’t even involve the query parser. Why issue a trivial query when you don’t have to?

Indenting HTML dropdown list. Until recently, only team administrators had to use these pages, so we just made it work in Mozilla Firefox and left the other browsers out in the cold. Now that we have some new features that need this capability, I decided to write-up a quick page to demonstrate each technique we tried and how each browser renders them. You can see the investigation and results below. Enjoy.

Update (2009-06-29): Andreas Stieger points out that is an possibility, here. Unfortunately, for our purposes, we needed multiple levels of indentation and the options must be selectable. , while easy to implement and relatively consistent rendering across browsers, fails to meet these criteria.

This first dropdown uses only CSS to attempt to indent the select options. Also, CSS bold property is being used to style the top-level items while italics are used to style the second-level items. This ideal rendering was produced by Mozilla Firefox 3.0.6 with no alterations.

Select dropdown indentation using CSS styles

This is how your browser renders the HTML for this technique. View the source to see exactly how it’s done.

This next dropdown uses nonbreaking space ( ) characters to indent the sub-items. The bold and italic items from the previous attempt are being left in place. Three characters for each level of indentation seem to look the best on most browsers. This ideal rendering was produced by Mozilla Firefox 3.0.6 with no alterations.

Select dropdown indentation using

This is how your browser renders the HTML for this technique. View the source to see exactly how it’s done.

Now, em dashes (—) are used for indentation instead of nonbreaking spaces, along with a trailing standard space. Bold and italics are still in place. This ideal rendering was produced by Mozilla Firefox 3.0.6 with no alterations.

Select dropdown indentation with —es

This is how your browser renders the HTML for this technique. View the source to see exactly how it’s done.

Now, the em dashes (—) used for indentation are being styled as white-on-white, so they should disappear. Bold and italics are done using and tags. This ideal rendering was produced by rendering the previous strategy in Mozilla Firefox 3.0.6 and removing the dashes by hand.

Select dropdown indentation using whitened —es

This is how your browser renders the HTML for this technique. View the source to see exactly how it’s done.

After trying these techniques on the major web browsers, here’s what I found:

Browser CSS nbsp mdash white mdash (