JNDI Datasource v/s Regular Datasource

[Franklin Antony]

Dear All,
We have an application which are deploying on Oracle Application Server's OC4J Container. The confusion I seem to be in is whether to use a JNDI Datasource(ofcourse as a spring manged bean) or a Regular Datasource to access the database. It would be more clear with a piece of code.

Should I use

    <bean id="jndiDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
     	<property name="jndiName">       
     		<value>java:comp/env/jdbc/HomeTestDB</value>
	  </property>
	</bean>

or

  <bean id="dataSource" class="<SomePolledDataSource>" destroy-method="close">
		<property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
		<property name="url" value="jdbc:oracle:thin:@localhost:1521:home"/>
		<property name="username" value="scott"/>
		<property name="password" value="tiger"/>
		<property name="autoCommit" value="true"/>
        <property name="suppressClose" value="true"/>
	</bean>

I would really like to know what would be the advantages/disadvantage of one over the other and what is the best practice in implementing this.

Thanks in advance,
Franklin

[al0]

You have to ask you server administrator. It is mostly policy matter.
Your application is not affected by this decision.

Dear All,
We have an application which are deploying on Oracle Application Server's OC4J Container. The confusion I seem to be in is whether to use a JNDI Datasource(ofcourse as a spring manged bean) or a Regular Datasource to access the database. It would be more clear with a piece of code.

Should I use

    <bean id="jndiDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
     	<property name="jndiName">       
     		<value>java:comp/env/jdbc/HomeTestDB</value>
	  </property>
	</bean>

or

  <bean id="dataSource" class="<SomePolledDataSource>" destroy-method="close">
		<property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
		<property name="url" value="jdbc:oracle:thin:@localhost:1521:home"/>
		<property name="username" value="scott"/>
		<property name="password" value="tiger"/>
		<property name="autoCommit" value="true"/>
        <property name="suppressClose" value="true"/>
	</bean>

I would really like to know what would be the advantages/disadvantage of one over the other and what is the best practice in implementing this.

Thanks in advance,
Franklin

[belugabob]

For me, the big advantage of the JNDI approach is that you can deploy the same WAR file (Without any changes) to several servers and have each server configured to use a different database instance.

This separates application configuration (your spring context files) from deployment configuration (Your web server files), resulting in a much more flexible arrangement.

[Franklin Antony]

Well actually I am looking more into the best practice in the industry. Policy wise, I will be making the decision. I have notice in this whitepaper http://www.springsource.com/whitepapers that its suggested to use your JNDI Datasource. Following is an extract from the artice

ESTABLISH AN EFFECTIVE BLUEPRINT
The secret to establishing an effective blueprint is to take full advantage of your
deployment platform. Because Spring keeps environmental dependencies out of
your application code this becomes much easier to do.
For database connection pools, if you are running on an application server then
use a pool configured through the administration console and configure Spring
to look the reference up via JNDI. For example, use
<jee:jndi-lookup id="dataSource"
jndi-name="jdbc/MyDataSource"/>
Instead of
<bean id="dataSource"
Spring in Production // 12

Now this is confusing me when you say its more of a policy. Again if I were to chose a JNDI datasource , what should be the TransacationManager in place ???

Thanks again,
Franklin

[al0]

It is matter of policy established by server administrator.
It may wish to configure JNDI-datasource for you or allow you to configure it itself or may prohibit its usage at all.

Concerning transaction manager - JNDI is only a way to obtain datasource, it well may be the same datasource implementation that you would use yourself (e.g. Apache DBCP or C3P0). Its functionality does not depend on the way it was obtained. So you use the same transaction manager.

Well actually I am looking more into the best practice in the industry. Policy wise, I will be making the decision. I have notice in this whitepaper http://www.springsource.com/whitepapers that its suggested to use your JNDI Datasource. Following is an extract from the artice




Now this is confusing me when you say its more of a policy. Again if I were to chose a JNDI datasource , what should be the TransacationManager in place ???

Thanks again,
Franklin

[Franklin Antony]

Thanks a lot for clearing the confusion on the policy. However JNDI datasource is allowed and permitted on our Oracle Application Server. So as per the recommendation would it be preferable to stick to a JNDI Datasource.

Belugabob did mention quite some interesting advantages and I am liking it. But in terms of performance wouldn't it be better to take the advantages of the application server in performing database task? Also does the whitepaper hint in the same lines!!!

Well when I was using the classic spring managed datasource, I was using C3P0 for pooling. The transaction manager was just a DataSourceTransactionManger(Just using JdbcTemplate no ORMs). However now when I move to Oracle Apps Server we create a Datasource from the Admin console. Assuming this is a OraclePooledDatasource can I still use a DataSourceTransactionManger?

Thanks,
Franklin.

[al0]

Belugabob did mention quite some interesting advantages and I am liking it.

This advantage is not so big - it assumes that all servers use the same jndi-name for required datasource in JNDI, but typically is is not so.
Each server team has its own naming convention And you can not assume that you would be allowed to create datasource with name provided by you.

[QUOTE]
But in terms of performance wouldn't it be better to take the advantages of the application server in performing database task? Also does the whitepaper hint in the same lines!!!
[/QOUTE]
I guess you have mixed up application server and database server. Article (quite properly) suggests to off-load as much of persistense logic to DB, using stored procedures. It does not suggest " to take the advantages of the application server in performing database task", especially as such advantages do not exist. Really, application server as such knows nothing about databases.

Well when I was using the classic spring managed datasource, I was using C3P0 for pooling. The transaction manager was just a DataSourceTransactionManger(Just using JdbcTemplate no ORMs). However now when I move to Oracle Apps Server we create a Datasource from the Admin console. Assuming this is a OraclePooledDatasource can I still use a DataSourceTransactionManger?

Why not? It still conforms to JDBC standard. But if you are in doubt, replace c3p0 with OraclePooledDatasource in your context and test it. BTW, I would prefer to stick with c3p0 and try to persuade server administrator to configure it in JNDI.

Regards,
Oleksandr

[Franklin Antony]

Thanks Oleksandr. The discussion seems to be getting really interesting

I believe the issue with having a JNDI Datasource name wouldnt be very evident. IMHO I think there is step in any app server administration task where you can map the name of the JNDI Datasource mentioned in your web.xml with the any arbitrary datasource defined on the server. Atleast I know I have done it on Tomcat. You define the datasource resource in the config.xml and the resource link in server.xml.[Please correct me if I am wrong on this]. So I wouldnt worry too much on that.

Well regarding the app server and the db server what I meant by DB task was just the connections and session management not the actual execution of queries.My mistake for not putting it across correctly. However....

For database connection pools, if you are running on an application server then
use a pool configured through the administration console and configure Spring
to look the reference up via JNDI. For example, use
<jee:jndi-lookup id="dataSource"
jndi-name="jdbc/MyDataSource"/>
Instead of
<bean id="dataSource">

What is the implication of this above recommendation. Why is it preferred , a JNDI lookup way over the classic datasource bean approach?[Apart from the admin policies]

[al0]

As far as understand that mapping is not application specific, am I wrong?
But I do not say that JNDI-datasource is undesirable, just that it advantages may be not so big. What you lost with JNDI-datasource is a freedom to configure datasource according to your needs (especially, if it used by several applications).

Application server does not manage connections by itself (unless your application is targeted for a managed environment, like EJB container). Spring manages connections (and eventually transactions) for you.

Taking datasource from JNDI provides no advantages for appication as such, mainly advantage is for server administrators providing for easier and more unified resource management and changes of the configuration (e.g. by migration of the database to another server).


Regards,
Oleksandr

Thanks Oleksandr. The discussion seems to be getting really interesting

I believe the issue with having a JNDI Datasource name wouldnt be very evident. IMHO I think there is step in any app server administration task where you can map the name of the JNDI Datasource mentioned in your web.xml with the any arbitrary datasource defined on the server. Atleast I know I have done it on Tomcat. You define the datasource resource in the config.xml and the resource link in server.xml.[Please correct me if I am wrong on this]. So I wouldnt worry too much on that.

Well regarding the app server and the db server what I meant by DB task was just the connections and session management not the actual execution of queries.My mistake for not putting it across correctly. However....


What is the implication of this above recommendation. Why is it preferred , a JNDI lookup way over the classic datasource bean approach?[Apart from the admin policies]

[Franklin Antony]

Well i believe since we are using OC4J I am going to stick to the class bean datasource and no JNDI.

Reasons are here.....
http://pjboyle.revelate.ie/?p=13
http://forums.oracle.com/forums/thre...654967�

Kudos,
Franklin.