Connecting to a Data Source Using an IDD

Step 2: Connecting to the data source

Establishing a connection means different things for different data sources. For some it means logging in with a username and password. For others it means calling some initialization routines through an API. In some cases, such as with a web-based resource, there is no persistent connection, though one could send a test query to check that the URL is correct, and that the remote site appears to be formatted as expected.

The openConnection method in your driver class is what K2 uses to create a new connection. This method returns a new connection object, which represents a single active connection to the data source. This means that if the data source requires the driver to open and maintain a "session", that session must already be open by the time the object is returned to K2. Usually the session is opened in the constructor of your connection class. If your connection class wants to, say, open the session in a separate thread, it will have to provide a run method, which you will have to call in the openConnection method of your driver class after you create a connection object.

openConnection may be called multiple times by K2, if the driver properties file specifies that more than one connection should be maintained. K2 manages the pool of connections at a level above the IDD, so the IDD writer does not need to be concerned about creating or maintaining more than one connection.

The openConnection method takes two parameters, both of which are derived from the driver properties file. The first is a name used to represent the connection to the data source. It is this name that K2 uses for the native query function, described earlier. openConnection must pass this name to your connection object's constructor in order for the native query function to work.

The second parameter to openConnection is a (possibly null) K2.absyn.expns.absynRecord containing additional values taken from the driver properties file. This mechanism is intended to allow changes to the properties file to affect the connections made by the driver. For example, the JDBC driver, a generic driver that can connect to any JDBC-enabled database, gets database-specific information, such as the hostname and port number of the database, through this parameter.

You must also implement the close method in your connection class. This is called by K2 when it wants to shut down the driver. Here again you should do whatever is appropriate for your data source, like disconnect from the database, or close the API.

Once K2 can open and close a connection through your driver, you're ready to process queries.


[Tech Docs Index]