JNDI

Java Naming and Directory Interface (JNDI)

Using JNDI, applications running in distributed environment, helps to look up services independently.

How JNDI is useful?

  1.  During deployment sequence, the same JNDI name can be used in different servers.
  2.  It helps to provide security of credential leakage to the user groups like developer, testers, stagers etc, because the credentials are configured in the server not in the application.
  3.  Connection Pooling can be achieved

How to use JNDI?
In order to use, JNDI classes and service providers should be there
The service provider may be :

  1. Lightweight Directory Access Protocol (LDAP)
  2. Common Object Request Broker Architecture (CORBA)
  3. Common Object Services (COS) name service
  4. Java Remote Method Invocation (RMI) RegistryThe objects needs to be created and registered so that , they can be further used for lookup.

How to configure JNDI in tomcat?
In tomcat environment we can configure JNDI in 3 different places
1. Inside the application using context.xml in META-INF directory.
2. Inside the tomcat server context.xml : Inside the apache-tomcat/conf directory we can configure. This can be helpful when multiple application needs the same database.
3. Both in server.xml and context.xml

NB: The database driver jar should be present in the tomcat lib directory

<Resource name="jdbc/lookupName" 
global="jdbc/lookupName" 
auth="Container" 
type="javax.sql.DataSource" 
driverClassName="com.mysql.jdbc.Driver" 
url="jdbc:mysql://localhost:3306/hdi" 
username="hiuser" 
password="hiuser" 

maxActive="100" 
maxIdle="20" 
minIdle="5" 
maxWait="10000"/>

In order to use it in java program we have to use the followng
DataSource ds = (DataSource) ctx.lookup(“java:/comp/env/jdbc/lookupName”);

JDBC Connection Pooling in jaspersoft

How JDBC Resources and Connection Pools Work Together in Jasper Report’s server

 

JasperReports Server can access any database using the JDBC (Java DataBase Connectivity) API. We can configure two types of data sources in the repository:

  • JDBC data source – Establishes a direct connection to the database server using its JDBC driver. JasperReports Server configures and manages the connections to the database. By default, the maximum number of simultaneous connections for each data source is five
  • JNDI data source – Calls the JNDI (Java Naming and Directory Interface) service of the application server to locate a database connection. The application server manages the connections to the database and shares them between all applications that it hosts. The configuration of the application server determines the number of connections that are shared.

 

At runtime, here’s what happens when Jasper Report’s server connects to a database:

 

  1. The Jasper Server gets the JDBC resource (data source) associated with the database by making a call through the JNDI API.

Given the resource’s JNDI name, the naming and directory service locates the JDBC resource. Each JDBC resource specifies a connection pool.

  1. Via the JDBC resource, the Jasper Server gets a database connection.

Behind the scenes, the server retrieves a physical connection from the connection pool that corresponds to the database. The pool defines connection attributes such as the database name (URL), user name, and password.

  1. Now that it is connected to the database, the server can read the database.

The server access the database by making calls to the JDBC API. The JDBC driver translates the application’s JDBC calls into the protocol of the database server.

Server doesn’t have to validate every single time the server uses the connection, which improves performance. So when user runs a report, the server requests a connection from the pool. When the thread is finished using the connection, it returns it to the pool, so that it can be used by any other threads.

Once the report is rendered and user does not perform any action on report like passing parameter etc, then connection sits idle. JDBC Connection pooling enables the idle connection to be used by some other thread. When the user does not access the DB, the server automatically returns the connection to connection pool after certain time. Once it’s back in the pool, the connection is available.