The Red Hat Database JDBC drivers are thread-safe. Consequently, if your application uses multiple threads, you do not have to worry about complex algorithms to ensure that only one uses the database at any time.
If a thread attempts to use the connection while another one is using it, the pending thread will wait until the other thread has finished its current operation. For a regular SQL statement, the operation consists of sending the statement and retrieving any ResultSet (in full). For a Fastpath call (for example, reading a block from a LargeObject), it is the time to send and retrieve that block.
This is fine for applications and applets, but it can cause a performance problem with servlets. With servlets you can have a heavy load on the connection. If you have several threads performing queries, each but one will pause, which may not be what you are after.
To solve this, you could create a connection pool. Whenever a thread needs to use the database, it asks a manager object for a connection. The manager hands a free connection to the thread and marks it as busy. If a free connection is not available, a new one is opened. Once the thread has finished with it, it returns it to the manager who can then either close it or mark it as free. The manager would also check to see if the connection is still alive and remove it from the pool if it is dead.
The advantage of a connection pool is that threads will not be affected by the bottleneck caused by a single database connection. The disadvantage is that the load on the database server is increased as a backend process is created for each connection. What method you choose depends on your application's requirements.