Using JNDI to connect to the database

Question

This may sound like a question about a noob, but this is the first time I step into the territory of a database. From here I have information that

The most efficient way to implement communication between the server and the database is to create a connection pool database. Creating a new connection for each client request can be very time-consuming, especially for applications that constantly receive a large number of requests.

and the tutorial uses the JNDI data source.

My application is also similar (but I won’t use Tomcat, only sockets) and my server will receive requests from several clients, but I don’t understand why I should use the JNDI data source, why the server supports one open database connection, and upon receipt of the client’s request, it processes the request and transfers the data to the client.

In the worst case, if I need JNDI, how can I implement it using my server application?

Answer 1

So is this a client application? DriverManager#getConnection() application and database usually talk to each other using the connection obtained with DriverManager#getConnection() ? If so, then you do not need JNDI to make the connection pool work. The only thing in question will be enough. For example, C3P0 or Apache Commons DBCP (I would recommend C3P0, DBCP is one-way). Just replace DriverManager#getConnection() with it.

Edit: Reply to your comments:

The server will talk to the database, and the clients will connect to the server, so I won’t know if this client application should be called.

I actually mean a simple Java application with vanilla coverage that does not run inside the Java EE container. Pascal put it better.

Actually, I'm a little confused about how pooling works, is each connection running on its own thread? is there any document / book to help me better understand these concepts with regard to unconnected joining?

To start, the connection pool opens the connection and holds it open until a timeout is configured. Pooling wraps / beautify a mix with its own implementation. A connection pool can simultaneously open and hold a configured number of connections. When you call getConnection() , it will immediately provide you with an already open connection. When you call close() on the connection, it will return the connection to the pool for future requests. This means that you still have to write JDBC code in the usual way: get and close Connection , Statement and ResultSet in the shortest possible area. Close all of them in the finally block. If your JDBC code is already well written, you really only need to replace DriverManager#getConnection() . Since you must open and close Connection in the same method block, it usually starts in the same thread. The connection pool will worry that Connection will not be received by another thread in the meantime, until your code calls close() on Connection .

You can find a good article here to understand how the connection pool works under the hood (take care: do not use it for production and do not set it on fire, just get the whole idea). For real work, use the existing carefully designed and reliable pooling structure.

Answer 2

My application is also similar (but I won’t use Tomcat, only sockets) and my server will receive requests from several clients, but I don’t understand why I should use the JNDI data source, why the server supports one open database connection, and upon receipt of the client’s request, it processes the request and transfers the data to the client.

Well, you could. But what if you have multiple clients, and if you have to perform simultaneous requests? Of course, you can keep one connection open for each client, but it does not scale very well (which may not be a problem in your context). However, the traditional way to solve this problem is to use the connection pool (and get additional services, for example, checking the connection, renewing the connection) and using it to get the connection “on demand”.

If you are not in the context of a J2EE container, use a stand-alone implementation of the connection pool, for example c3p0 (prefer c3p0 over DBCP which is considered obsolete and less reliable when loading) and forget JNDI (which is the standard way to get the connection pool descriptor when running inside the J2EE container).

Look at the c3p0 documentation for more details and sample code, this is pretty clear.

Answer 3

JNDI for database connections solves a situation where application developers are not the ones who manage database connections.

In this way, the application developer can specify how many concurrent connections their application requires. Then, the server administrator will determine the database connection pool. The application is viewing the pool.

Neither the application nor the application developer should know the credentials required to connect to the database. In addition, the server administrator can determine the connection pool in different sizes depending on the deployment environment, and the application is isolated from knowledge of such differences.

Since your application is the server itself, the application is therefore responsible for identifying and managing the connection (s) in the database.

Answer 4

Drop another link to another connection pool: BoneCP ( http://jolbox.com ). Tests show that it is faster than C3P0 / DBCP.

PS I did not see DBCP lock in my multi-threaded tests.