No, I haven't been able to find the link to the article on the IBM DeveloperWorks site. I'd appreciate if anyone else could.
I'll start with PreparedStatements from first principles, then we can see where we get from there. (This is off the top of my head but hopefully I won't get things too wrong)
The first concept to understand is that the SQL you write is not the same as the code that gets executed on the database. In the same way we write
Java code that gets compiled into byte code, and it is the byte code that gets executed, SQL statements get compiled into DB code and it is this code that gets run by the database.
There is a lot of performance tweaks and database specific stuff that goes into this SQL compilation, but an important point is that it isn't free. If you execute 10 SQL queries, the database must compile and tweak 10 statements and this before it even begins the search.
It is also possible for a database to detect that it has already run a particular query and that it does not need to compile it again. If it still has the compiled version it can reuse it with the same query.
If you run the SQL query "SELECT * from myTable where id=27", this will get compiled into a statement that will only match this exact query. If you then run "SELECT * from myTable where id=28", the database won't match the two together. It will recompile the new query even though it is almost exactly the same as the previous one.
Some databases also support variables in SQL statements, so that it can compile the SQL without knowing what the value is. Now if we compile the SQL statement "SELECT * from myTable where id=?", the statement will only be compiled once even if we run it with ?=27 and ?=28 or any other value. This is good if we run the same query often.
Now on to how this relates to JDBC:
When you use a Statement, it works like the first case where it assumes it is a new query every time you run it and is unlikely to be able to rely on cached queries in the database.
If you use a PreparedStatement (as in my first post), it hooks into the compiled statement caching on the database invisibly. You don't have to help it detect cached statements. If there is one there, it will be used. It this sense PreparedStatements are no worse, since they may need to be compiled every time, but a Statement would have to do this anyway.
If I understand your concept of 'handle', you don't need to worry about it. It's managed for you invisibly by the driver.
The last point I'd like to make is that not all databases support PreparedStatements, even if the driver you have does. Since you have no idea what happens on the database (you only talk to the JDBC Driver), it is possible for the PreparedStatement to fake this support, even though what is really happeneing is the PreparedStatement is executing a new query every time.
I'll give it afew more minutes ooking for a better article, but this might be all you'll get...