How does JDBC Connection Pooling work?

This post is an excerpt from the jtracer blog.

Overview

The Apache commons DBCP component provides Connection pooling for JDBC connections. In this blog I am going to use JTracer to reveal how DBCP works internally.

JDBC Primer

To connect to a database using JDBC a java.sql.Connection is needed. For creating a Connection, a JDBC driver needs to be loaded. Connection parameters like url and credentials should also be set. Once a Connection is obtained you can create a Statement to execute queries. After the Statement and Connection are used, they should be closed to clean up the resources. The DataSource API as part of the javax.sql package provides an alternate way to create connections.

Creation of Connections is an expensive process. It is better to use a connection pool that will re-use Connections for running queries rather than creating only new Connections. The DBCP project from Apache provides a BasicDataSource which also implements Connection pooling.

Continue

Continue reading at the jtracer blog.

Overview of OSGi

What is OSGi?

OSGi is a module system and service platform for the Java platform.

For the module system, it extends the code level visibility controls that Java provides via the private, protected, public and package-private access. An application is usually packaged as multiple jars in java. Some of these are external libraries. With OSGi it is possible to specify version for a jar and dependency information between jars.

OSGi enables Service Oriented Architecture in a Virtual Machine. It provides APIs for providing a way to register services, discover and bind to them.

Specifications

The OSGi Alliance is an industry backed non-profit organization that manages the OSGi specifications. There are a many implementations like Apache Felix, Eclipse Equinox and Knopflerfish. Building on top of the core OSGi framework are runtimes that provide additional services like Apache Karaf.

Architecture

OSGi Platform

The OSGi platform is composed of the Framework and Standard services. The framework is the runtime that implements and provides OSGi functionality. The standard services define reusable APIs for common tasks.

Core framework

The core framework itself can be broken down into 3 layers - Module, Lifecycle and Service. Each layer is dependent on the layer below. The Module layer has to be used by an application but the Lifecycle and Service layers are optional.

1. Module Layer
In OSGi the unit of modularity is called a Bundle. A Bundle is basically a jar file containing additional metadata in headers with an additional file - META-INF/MANIFEST.MF.

Headers Bundle-SymbolicName and Bundle-Version are used to uniquely identify a Bundle and its version. Using the header Export-Package the Bundle can specify the packages that are visible to other packages. Import-Package and Require-Bundle are used to specify the dependencies of a Bundle.

2. Lifecycle Layer

There are 4 phases of a Bundle lifecycle

1. Installation - The bundle jar has to be installed first from a URL. The framework automatically resolves its dependencies based on the Import-Package and Require-Bundle headers. Resolution happens transitively for all the dependent bundle as well.
2. Execution - When the Bundles classes are first accessed or the bundle is explicitly started, it moves to a starting state
3. Update - Bundles may be updated to a different version using the API
4. Removal - Finally bundles may be uninstalled.

Some of the important APIs that allow this functionality are-
org.osgi.framework.BundleActivator
org.osgi.framework.BundleContext
org.osgi.frameword.Bundle

3. Service Layer

The OSGi framework allows registration of services, discovery and binding to them. Bundles may be installed and uninstalled allowing for dynamic services and possibly multiple implementations.

The org.osgi.framework.BundleContext class provides APIs for this service layer.

Services

An OSGi platform provides core services some of which are-

• Package Admin (org.osgi.service.packageadmin) provides the ability to control and reflect over bundle and package level resolution
• Start Level (org.osgi.service.startlevel) controls the relative order of bundle startup by assigning start levels to bundles
• Service Hooks (org.osgi.framework.hooks.service) allows bundles to monitor and limit service registry events and access

Some of the optional services are-

• Log (org.osgi.service.log) for logging by bundles
• HTTP (org.osgi.service.http) for a HTTP server with Servlet support
• Configuration Admin (org.osgi.service.cm) Manages bundle configuration data storage and injection
• Preferences (org.osgi.service.prefs) for management of Preferences
• Event Admin (org.osgi.service.event) for publish-and-subscribe and topic-based event notification

Summary

OSGi does provides some valuable extensions to the core java language. Just being able to specify packages to external clients allows to design APIs without leaking unnecessary information. Classpath resolution is also well managed.
The service layer further adds to the idea of well defined APIs.

Being based on plain java classes the framework does not feel heavy like EJBs. However figuring out how to use a particular runtime is not an easy task.

Integrating with existing code and converting them to bundles is also non-trivial. If jars are not well designed APIs then there is always a problem that there are some references that will never be cleaned causing a leak. Existing code also needs to be refractored to use the OSGi services of logging and configuration.

In all OSGi has value but there is also a cost to using the framework.

The Concurrency Revolution II

In Dec 2004 Mohnish had posted The Concurrency Revolution based on Herb Sutter's article on the multi-core paradigm shift in processors.

Well, it's time to read the follow up - Welcome to the Jungle .

Ubuntu Tour

I'm running a slightly old version of ubuntu .. trying to hold moving to the new UI. I wanted to have a peek at the current state.

Opened the Ubuntu Tour and expected to see a few screenshots. But ..

The tour is actually a working Ubuntu desktop built as an HTML page! Amazing. The dash works, the start bar works with date, volume etc and other basic controls. Some applications are just images which you can drag around. Thunderbird is more complex with demo emails. Firefox is the best because you can open other webpages.. recursive browsing.

When drafting this blog, noticed that the layout reconfigures when the width of the page changes.

HTML layouts have come a long way.

Know what libraries are used for this?

Simplicity

Simplicity is the ultimate sophistication - Leonardo da Vinci

Rich Hickey presented a fantastic talk, Simple made easy - "Rich Hickey emphasizes simplicity’s virtues over easiness', showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path."

Anders Hejlsberg mentioned simplexity in an interview a while back as well where he says "Let me first talk a little bit about how I view simplicity in general. No one ever argues that simplicity isn't good, but people define simplicity in a variety of ways. There's one kind of simplicity that I like to call simplexity. When you take something incredibly complex and try to wrap it in something simpler, you often just shroud the complexity. You don't actually design a truly simple system. And in some ways you make it even more complex, because now the user has to understand what was omitted that they might sometimes need. That's simplexity. So to me, simplicity has to be true, in the sense that the further down you go the simpler it gets. It shouldn't get more complicated as you delve down. "


Over time I have seen quite a few systems with too much complexity. And mostly it was not needed. Just a lot of code added without too much thought to design. More thought should be put into design and refractoring and testing.

It is also funny how this parallels to a sense of minimalistic design for design and architecture.