풀에서 JDBC 연결 닫기

풀에서 JDBC 연결 닫기

---

JDBC 사용을위한 표준 코드 섹션은 다음과 같습니다.

Connection conn = getConnection(...);
Statement  stmt = conn.conn.createStatement (ResultSet.TYPE_SCROLL_INSENSITIVE,
                                                ResultSet.CONCUR_READ_ONLY);
ResultSet  rset = stmt.executeQuery (sqlQuery);

// do stuff with rset

rset.close(); stmt.close(); conn.close();

질문 1 : Connection Pool을 사용할 때 마지막에 Connection을 닫아야합니까? 그렇다면 풀링의 목적이 상실되지 않습니까? 그렇지 않은 경우 DataSource는 Connection의 특정 인스턴스가 해제되고 재사용 될 수있는시기를 어떻게 알 수 있습니까? 나는 이것에 대해 약간 혼란 스럽습니다.

질문 2 : 다음 방법이 표준에 가깝습니까? 풀에서 연결을 얻으려는 시도처럼 보이며 DataSource를 설정할 수없는 경우 구식 DriverManager를 사용하십시오. 런타임에 어떤 부분이 실행되고 있는지조차 확실하지 않습니다. 위의 질문을 반복하면 그러한 방법에서 나오는 연결을 닫아야합니까?

고마워요-MS.

synchronized public Connection getConnection (boolean pooledConnection)
                                                        throws SQLException {
        if (pooledConnection) {
                if (ds == null) {
                        try {
                                Context envCtx = (Context)
                                        new InitialContext().lookup("java:comp/env");
                                ds = (DataSource) envCtx.lookup("jdbc/NamedInTomcat");
                                return ds.getConnection();
                        } catch (NamingException e) {
                                e.printStackTrace();
                }}
                return (ds == null) ? getConnection (false) : ds.getConnection();
        }
        return DriverManager.getConnection(
                "jdbc:mysql://"+ipaddy+":"+dbPort +"/" + dbName, uName, pWord);
}

편집 : 스택 추적이 보이지 않기 때문에 풀링 된 연결을 얻고 있다고 생각합니다.

---

Connection Pool을 사용할 때 마지막에 Connection을 닫아야합니까? 그렇다면 풀링의 목적이 상실되지 않습니까? 그렇지 않은 경우 DataSource는 Connection의 특정 인스턴스가 해제되고 재사용 될 수있는시기를 어떻게 알 수 있습니까? 나는 이것에 대해 약간 혼란 스럽습니다.

예, 물론 풀링 된 연결도 닫아야합니다. 실제로 실제 연결을 둘러싼 래퍼입니다. 커버 아래에서 풀에 대한 실제 연결을 해제합니다. 실제 연결이 실제로 닫히거나 새 getConnection()호출에 재사용 되는지 여부를 결정하는 것은 풀에 달려 있습니다 . 따라서 연결 풀을 사용하는지 여부에 관계없이 항상 모든 JDBC 리소스를 획득 한 블록 의 finally블록 에서 역순으로 닫아야 try합니다. Java 7에서는 try-with-resources문 을 사용하여 더 단순화 할 수 있습니다 .

---

다음 방법이 표준에 가깝습니까? 풀에서 연결을 얻으려는 시도처럼 보이며 DataSource를 설정할 수없는 경우 구식 DriverManager를 사용하십시오. 런타임에 어떤 부분이 실행되고 있는지조차 확실하지 않습니다. 위의 질문을 반복하면 그러한 방법에서 나오는 연결을 닫아야합니까?

예는 꽤 무섭습니다. DataSource응용 프로그램 전체 DB 구성 클래스의 일부 생성자 / 초기화에서 응용 프로그램을 시작하는 동안 한 번만 조회 / 초기화하면 됩니다. 그런 다음 getConnection()나머지 애플리케이션 수명 동안 하나의 동일한 데이터 소스를 호출 하면됩니다. 동기화 나 null 검사가 필요하지 않습니다.

또한보십시오:

• 다중 스레드 시스템에서 정적 java.sql.Connection 인스턴스를 사용하는 것이 안전합니까?
• JDBC 연결 풀링을 사용하고 있습니까?

---

The pools typically return you a wrapped Connection object, where the close() method is overridden, typically returning the Connection to the pool. Calling close() is OK and probably still required.

A close() method would probably look like this:

public void close() throws SQLException {
  pool.returnConnection(this);
}

For your second question, you could add a logger to show whether the bottom block ever runs. I would imagine though you'd only want one way or the other for the configuration of your database connections. We solely use a pool for our database accesses. Either way, closing the connection would be pretty important to prevent leaks.

---

Actually, the best approach to connection management is to not farm them out to any code anywhere.

Create a SQLExecutor class that is the one and only location which opens and closes connections.

The entire rest of the application then pumps statements into the executor rather than getting connections from the pool and managing (or mismanaging them) all over the place.

You can have as many instances of the executor as you want, but no one should be writing code that opens and closes connections on its own behalf.

Conveniently, this also lets you log all your SQL from a single set of code.

참고URL : https://stackoverflow.com/questions/4938517/closing-jdbc-connections-in-pool