Rule #2 - Use direct JDBC for persistence (remember this is how to do it the WRONG way)

 

By using JDBC directly, you increase the complexity of YOUR code or reduce its scale. You are forced to implement your own data paging, own transaction handling, and own cache strategy (but not necessarily your own cache). You are also likely to increase the weight on the garbage collector thereby reducing performance.

In the event that you handle techniques like paging the data that you load, you opt for more complexity (which is a corollary to increased entropy and bugs). In the event that you do the simple minded thing "select * from table where bla=?" then you increase the amount of memory utilization and risk forcing more frequent full garbage collections.

 

It is still possible to utilize caching via JBoss Cache or similar products, but you will likely have to implement the "strategy" yourself. If you do not do this, and just query the database, then you increase the load on the server because you must reload data for every request for every user (don't forget the garbage collector!). If you do opt to implement your own cache strategy (when to put, when to get) then you will increase the complexity of your code. The worst thing you could do is use the HTTP Session as a Cache.

 

It is still possible to use a transaction manager with direct-JDBC but you will have to write your own transaction handling. Meaning, you will have to decide when and if you want a transaction. This increases the complexity of your code while reducing its reusability. We'll talk more about this next time.

 

Note that DAOs and other said patterns reduce the coupling of this code, they do not address the problem itself. You still have to implement it and you still have the added complexity as a result.

 

Inverse - Use a automated persistence (such as Hibernate)

 

Using a persistence mechanism such as Hibernate or even CMP, you can take advantage of both eager and lazy loading thus paging the data appropriately. Furthermore, you can utilize second-level cache, thus reducing load from IO and garbage collection. Lastly, you can utilize managed transactions. What's more is that you get all of this for free. Again, do you want to own that (I've read that O-R mapping is as high as 60-80% of most modern business apps)? Let JBoss help!

 

Next up: How not to handle transactions. Previously: using the HTTPSession as a Cache