OK, you are probably right. I haven't done raw jdbc in years. Application server always use a connection pool and you don't really want to open a connection every time.
【在 w**z 的大作中提到】 : you need to close all of them, connection, resultset, prepare statement. : otherwise memory leak. : : you
【在 g*****g 的大作中提到】 : OK, you are probably right. I haven't done raw jdbc in years. Application : server always use a connection pool and you don't really want to open a : connection every time.
w*z
31 楼
connection pool implements close() method, it will put the connection back to the pool. But for sure, caller needs to close ResultSet and Statement.
I don't think you need to do that when using JdbcTemplate or Spring Data/ Hibernate/JPA. You probably don't need those at all with ORM.
【在 w**z 的大作中提到】 : connection pool implements close() method, it will put the connection back : to the pool. But for sure, caller needs to close ResultSet and Statement.
T*x
36 楼
也需要connection.close()才能put connection back to pool吧?
【在 w**z 的大作中提到】 : connection pool implements close() method, it will put the connection back : to the pool. But for sure, caller needs to close ResultSet and Statement.
c*e
37 楼
re
【在 T*******x 的大作中提到】 : 也需要connection.close()才能put connection back to pool吧?
w*z
38 楼
the connection pool implementation overrides the close method , if you call close on the connection, it will be put back to the pool.
【在 c*********e 的大作中提到】 : re
b*y
39 楼
call Ya, that's about right
【在 w**z 的大作中提到】 : the connection pool implementation overrides the close method , if you call : close on the connection, it will be put back to the pool.
m*t
40 楼
because most of JDBC drivers use native code ( like C, or C++ ), which create objects outside of java heap. Java GC cannot collect those native object memory. close() method inside finally block can guarantee the invocation of native memory release method provided by specific JDBC provider.
w*z
41 楼
this one is a pure Java: http://dev.mysql.com/doc/refman/5.6/en/connector-j-overview.htm Oralce JDBC thin driver is also written in Java http://docs.oracle.com/cd/E16655_01/java.121/e17657/overvw.htm Consider the following when choosing a JDBC driver for your application or applet: In general, unless you need OCI-specific features, such as support for non-TCP/IP networks, use the JDBC Thin driver. If you want maximum portability and performance, then use the JDBC Thin driver. You can connect to Oracle Database from either an application or an applet using the JDBC Thin driver. If you want to use Lightweight Directory Access Protocol (LDAP) over Secure Sockets Layer (SSL), then use the JDBC Thin driver. If you are writing a client application for an Oracle client environment and need OCI-driver-specific features, such as support for non-TCP/IP networks, then use the JDBC OCI driver. If you are writing an applet, then you must use the JDBC Thin driver. For code that runs in the database server and needs to access a remote database or another session within the same database instance, use the JDBC server-side Thin driver. If your code runs inside the database server and needs to access data locally within the session, then use the JDBC server-side internal driver to access that server.
【在 m*********t 的大作中提到】 : because most of JDBC drivers use native code ( like C, or C++ ), which : create objects outside of java heap. Java GC cannot collect those native : object memory. close() method inside finally block can guarantee the : invocation of native memory release method provided by specific JDBC : provider.