When developing a SQL application, there are two main benefits to this design:
- The application doesn't need to know how to get to the database.
- Most data sources support connection pooling, which has significant performance improvements over always obtaining a new connection in your application.
- Container-based: the credentials are stored in the JNDI definition on the server and applications do not provide any credentials. This is the most common choice, and thus the default setting.
- Application-based: the application must provide the credentials.
Note: Not all data sources support application-based authentication! Apache Tomcat's default data source implementation, for example, will throw an error if you try to use it.
The JDNI settings are visible when you select an SQL resource binding in the Deployment Descriptor editor. You can change the name of the data source of the type of authentication that will be used.
The code that you write does not care how the connection is being obtained, those details are left to the deployment descriptor. A quick snippet for connecting to a database and adding a new row:
ds SQLDataSource = SysLib.getResource("binding:DerbyConnection");add newRecord to ds;
Normally the JNDI configuration in your deployment descriptor is only used by the client application for obtaining the data source from the server, however if you are deploying to Apache Tomcat then we will also define the data source for you. If you are deploying to any other server type, you will need to define the data source on the server yourself (refer to the server's documentation for how this should be done). The reason we cannot do this for any type of server is that there is no standard for how to define the data source, the standard only covers how to access defined objects; every server does it differently.
I'll leave you with a tip: the IDE test server does support JNDI, but if you want to add connection pooling support to it then all you need to do is define an Apache Tomcat runtime at Window > Preferences > Server > Runtime Environments to take advantage of Tomcat's connection pooling support.