JNDI Data Source?

You may have seen the JNDI data source menu at the BI Publisher Admin page and have wondered what and when to use it.

What is JNDI?

So what is JNDI? JNDI stands for Java Naming and Directory Interface. Here is an excerpt from ‘Oracle Containers for J2EE Services Guide’.

---

“JNDI provides naming and directory functionality for J2EE applications and components. JNDI is defined independently of any specific naming or directory service implementation. This enables J2EE applications and components to access different naming and directory services using a single API. Different naming and directory service provider interfaces (SPIs) can be plugged in behind this common API to handle different naming services.

A J2EE-compatible application uses JNDI to obtain naming contexts. A naming context enables the application to retrieve J2EE resources including data sources, local and remote Enterprise Java Beans (EJBs), and JMS-administered objects such as topics and queues.”

---

So it’s basically a naming registry that you can find the resource that you’re looking for by using a common name among applications deployed on a same J2EE Web Application server. So once you have registered a JDBC data source at your J2EE Web Application server then you can use the same data source among the applications on the server while if you register the JDBC in one application then another application can not use it.

JDBC Connection Pool?

What makes this JNDI even more valuable for BI Publisher is you can use a JDBC connection pool through the JNDI. The JDBC Connection pool maintains a cache of physical database connections that can be reused. So even after the first client request closed a database connection the database connection itself still remains at the server. When the second client request comes in then it will use the same connection that was used for the previous client session. This is a connection pool so multiple clients can use the same connection to access to the same database. A connection pool improves performance and scalability by allowing multiple clients to share a small number of physical connections.

Typically you register a JDBC connection pool at a J2EE Web Application server then all the applications running on the server share the same JDBC connection pool through the JNDI.

Why JNDI Data Source?

There are some advantages of using the JNDI data source over the JDBC data source for the BI Publisher reporting.

First, it is a connection pool, so each client request to the database can share the JDBC connection instead of opening each of the connection. When you have multiple SQL base list of values for your report BI Publisher opens the database connection of each of the list of values so you end up opening many database connections for just one single report. Yes, this obviously will have an impact on your report performance and the server resource. If you have one JDBC connection pool and use it through the JNDI then the report doesn’t need to open the extra connection. I’ve seen this at several clients who had many parameters for one report and it made a good performance improvement after we switched to the JNDI data source.

Second, some times the DBA might not want to share the database schema name and password with the BI Publisher administrators. If the DBA also manages BI Publisher this is not a problem. But if not then this becomes to be a problem especially for a production environment. JNDI data source stores the schema name and password at the web application server level, not the application level.

Third, when you do a BI Publisher repository migration between environments such as Development, Testing, Production, you need to change the password for each environment after the migration because usually the password for the schema is different between the databases. By using this JNDI you don’t need to worry about this at least at the application level, in this case it’s BI Publisher.

So I’ll cover how to create the JNDI data source for BI Publisher with examples of Oracle OC4J and Oracle WebLogic servers from tomorrow, so stay tuned!