Why should I map the JDBC resource reference to the Data Source Alias and not to the name of the connection pool as registered in the JNDI Registry service?
Powerful and so simple: If you map the resource reference to the Data Source Alias – rather then hard code the name of the connection pool in the deployment descriptor, as would be the case with the pure J2EE approach – not only the Java code, but also the deployment descriptors of your J2EE components can remain untouched if you decide to move the application data to another database instances/schema. That means: The whole application is easily portable across database instances/schemas. Once deployed, the whole application remains valid and is easily able to work with any database instance/schema. The redirection to another database schema has become a simple administrative task: The server administrator is simply asked to reassign the Data Source Alias your application is using to another database connection pool, namely addressing the target database schema.
Related Questions
- Why should I map the JDBC resource reference to the Data Source Alias and not to the name of the connection pool as registered in the JNDI Registry service?
- Can FileMaker 7 products act as ODBC/JDBC client and/or data source on Mac OS X?
- How do I use Resource Shell to create JDBC Connection Factory Resources?
