Is statement.close () explicitly required in a federated join environment?

I am using the connection pool in my application. My question is:

Explicitly, do you need to close the statement before closing the connection if you join the connection pool?

In a connection, the connection to the federated environment does not close (but returns back to the pool of free connections). I checked the functional specifications of jdbc 4.0. In paragraph 9.4.4, he clearly states that:

Closing Connection Objects An application calls the Connection.close method to indicate that it has finished using the connection. All Statement objects created from this Connection object will be closed when the close method is called on the object. When a connection is closed, any attempt to access any of its methods, with the exception of the close, isClosed, or isValid methods, will throw an SQLException.

Thus, jdbc specifications require closing the entire statement while closing the connection. Thus, is it applicable only to a jointed environment without a joint or is it also applied to a jointed joint medium?

For me, this does not matter in the case of a unified environment, because we are coding the interface ( java.sql.Connection and java.sql.Statement ). Therefore, we are not worried about the implementation, and the parent class ( java.sql.Connection ) does not have any information about the child / impementation class (Vendor implementation class).

+4
source share
3 answers

Any object that has functions close (), release (), destroy (), etc., offers automatically (of course, you should read the API documentation, there may be different names used for this purpose) that the object needs to be called this method ensures that object resources are released when the object is no longer in use. There is no reason to provide such a method if an object can do this on its own.

In the case of java.sql.Connection, the connection is not actually closed, it is simply dropped into the pool as an available connection, but this is internal material that you care about.

+4
source

That's right. Perhaps the implementation of Statement will have other resources that need to be released or have some other relationship with the connection. You do not know and should not know the implementation details.

Your approach is absolutely right: code for the interface and avoid small β€œshort cuts” that may bite you later. (Even if it works now, it may not appear in a future version of the pool or join classes.)

+7
source

In my experience, some JDBC drivers have errors. They seem to work best if you close all statements (and ResultSets) manually. Otherwise, I saw resource leaks that should not have been preserved after the connection was closed.

+2
source

Source: https://habr.com/ru/post/1285681/


All Articles