T*******x
发帖数: 8565 | 1 比如在一个函数内部，connection是一个local variable。
函数结束的时候为什么不自动释放jdbc connection？
做不到吗？内部有什么难度吗？ |
w**z
发帖数: 8232 | 2 it is more than memory, it is resource. Java 7 comes with closable to
rescure.
【在 T*******x 的大作中提到】
: 比如在一个函数内部，connection是一个local variable。
: 函数结束的时候为什么不自动释放jdbc connection？
: 做不到吗？内部有什么难度吗？
|
f*******t
发帖数: 7549 | 3 GC是一个独立的thread，变量生命周期结束后不确定什么时候会被释放。 |
a*w
发帖数: 4495 | 4 说句题外话，即使只涉及内存，有些内存GC也不会动，比如
obsolete object reference
【在 w**z 的大作中提到】
: it is more than memory, it is resource. Java 7 comes with closable to
: rescure.
|
c*********e
发帖数: 16335 | 5 conn.close();
不就行了。
【在 T*******x 的大作中提到】
: 比如在一个函数内部，connection是一个local variable。
: 函数结束的时候为什么不自动释放jdbc connection？
: 做不到吗？内部有什么难度吗？
|
w**z
发帖数: 8232 | 6 不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
是没用的。
try-with-resource is a bit better
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
|
w**z
发帖数: 8232 | 7 不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
是没用的。
try-with-resource is a bit better
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
|
c*********e
发帖数: 16335 | 8 有的把conn.close()还放在finally里。这玩艺都是约定俗成了，抄人家的code,也都是
这么写的。
c#里用using( ).
【在 w**z 的大作中提到】
: 不过，Java的resource close 是比较恶心，conn.close 也要放在try catch 里， 都
: 是没用的。
: try-with-resource is a bit better
|
T*******x
发帖数: 8565 | 9 据说在finally里写是最好的:
try {
----Connection connection = dataSource.getConnection();
----Statement statement = connection.prepareStatement(sql);
----ResultSet result = statement.executeQuery();
...
} catch (Exception e) {
...
} finally {
----if (result != null) {
--------try {
------------result.close();
--------} catch (Exception e) {
--------}
----}
----if (statement != null) {
--------try {
------------statement.close();
--------} catch (Exception e) {
--------}
----}
----if (connection != null) {
--------try {
------------connection.close();
--------} catch (Exception e) {
--------}
----}
}
这么一大堆，好像是标准吧？
感觉挺麻烦的。而且一个函数中只能一个try跟一个finally。
多个try和多个finally，我感觉出口很复杂，可能会出漏洞。
【在 c*********e 的大作中提到】
: conn.close();
: 不就行了。
|
g*****g
发帖数: 34805 | 10 I think close connection is good enough. Or you can use JdbcTemplate and you
don't need to do anything at all.
【在 T*******x 的大作中提到】
: 据说在finally里写是最好的:
: try {
: ----Connection connection = dataSource.getConnection();
: ----Statement statement = connection.prepareStatement(sql);
: ----ResultSet result = statement.executeQuery();
: ...
: } catch (Exception e) {
: ...
: } finally {
: ----if (result != null) {
|
|
|
w**z
发帖数: 8232 | 11 you need to close all of them, connection, resultset, prepare statement.
otherwise memory leak.
you
【在 g*****g 的大作中提到】
: I think close connection is good enough. Or you can use JdbcTemplate and you
: don't need to do anything at all.
|
w**z
发帖数: 8232 | 12 都这么写。写个helper会好一点。
【在 T*******x 的大作中提到】
: 据说在finally里写是最好的:
: try {
: ----Connection connection = dataSource.getConnection();
: ----Statement statement = connection.prepareStatement(sql);
: ----ResultSet result = statement.executeQuery();
: ...
: } catch (Exception e) {
: ...
: } finally {
: ----if (result != null) {
|
e*****t
发帖数: 1005 | 13 helper还是麻烦，等有java 8closure应该会好些吧。
【在 w**z 的大作中提到】
: 都这么写。写个helper会好一点。
|
g*****g
发帖数: 34805 | 14 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
|
w**z
发帖数: 8232 | 15 java 7 added try with resource.
【在 e*****t 的大作中提到】
: helper还是麻烦，等有java 8closure应该会好些吧。
|
d****i
发帖数: 4809 | 16 Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
you
【在 g*****g 的大作中提到】
: I think close connection is good enough. Or you can use JdbcTemplate and you
: don't need to do anything at all.
|
r*****s
发帖数: 985 | 17 同意，
Criteria API真是寫的蛋疼也看得蛋疼
【在 d****i 的大作中提到】
: Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
: 至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
:
: you
|
g*****g
发帖数: 34805 | 18 俺们开始用Spring Data，好使。常见的query都不用写了。
【在 d****i 的大作中提到】
: Spring JDBC很好，把raw JDBC的麻烦都省掉了，看到一片文章说用Spring JDBC以后甚
: 至连Hibernate, JPA这些ORM都不用了，简单，直接又轻便。goodbug有何高见？
:
: you
|
r*****s
发帖数: 985 | 19 嗯,
spring data好使，
要拋棄criteria api
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
|
w**z
发帖数: 8232 | 20 我们用 bonecp conneciton pool，performance 够好， 就是写SQL 比较蛋疼。想来
ORM 还是有用的。
有空要学习一下spring data， 我们只用Spring 的DI
【在 r*****s 的大作中提到】
: 嗯,
: spring data好使，
: 要拋棄criteria api
|
|
|
P****i
发帖数: 12972 | 21 bonecp+mybatis performance很好
【在 w**z 的大作中提到】
: 我们用 bonecp conneciton pool，performance 够好， 就是写SQL 比较蛋疼。想来
: ORM 还是有用的。
: 有空要学习一下spring data， 我们只用Spring 的DI
|
d****i
发帖数: 4809 | 22 这个很不错，那JdbcTemplate的那些query都可以省了？
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
|
w**z
发帖数: 8232 | 23 我们都用stored procedure， 这还那么有用吗？
【在 d****i 的大作中提到】
: 这个很不错，那JdbcTemplate的那些query都可以省了？
|
w**z
发帖数: 8232 | 24 我都人工写DAO layer， 就几个不复杂的query， 用ORM嫌麻烦，但人工写db column
mapping到 POJO， 确实烦。但一个service就几个POJO， 也不复杂。。。
【在 P****i 的大作中提到】
: bonecp+mybatis performance很好
|
b******y
发帖数: 9224 | 25
en, 我也是人工写，简单。关键是，用ORM的话，你学不到底层的东东
【在 w**z 的大作中提到】
: 我都人工写DAO layer， 就几个不复杂的query， 用ORM嫌麻烦，但人工写db column
: mapping到 POJO， 确实烦。但一个service就几个POJO， 也不复杂。。。
|
o***i
发帖数: 603 | 26 我也是人工写，但是就是复制粘贴改改参数嘛，有什么底层的东东？
【在 b******y 的大作中提到】
:
: en, 我也是人工写，简单。关键是，用ORM的话，你学不到底层的东东
|
o***i
发帖数: 603 | 27 有sql server支持么？
【在 g*****g 的大作中提到】
: 俺们开始用Spring Data，好使。常见的query都不用写了。
|
b******y
发帖数: 9224 | 28
en, 我没说清楚。是没啥东西了。
底层我们用的是Apache的multi-threaded object pooling library. 就是用来做jdbc
connection的那一层。
【在 o***i 的大作中提到】
: 我也是人工写，但是就是复制粘贴改改参数嘛，有什么底层的东东？
|
w**z
发帖数: 8232 | 29 dbcp ?
jdbc
【在 b******y 的大作中提到】
:
: en, 我没说清楚。是没啥东西了。
: 底层我们用的是Apache的multi-threaded object pooling library. 就是用来做jdbc
: connection的那一层。
|
T*******x
发帖数: 8565 | 30 connection pool也需要getConnection，
用完之后也要close吧。
【在 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
发帖数: 8232 | 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.
【在 T*******x 的大作中提到】
: connection pool也需要getConnection，
: 用完之后也要close吧。
|
b******y
发帖数: 9224 | 32
Yes, it is quite good and robust. Also, simple enough
【在 w**z 的大作中提到】
: dbcp ?
:
: jdbc
|
g*****g
发帖数: 34805 | 33 都可以省了没有，简单的省了。不是太复杂的写个interface method足够。
【在 d****i 的大作中提到】
: 这个很不错，那JdbcTemplate的那些query都可以省了？
|
g*****g
发帖数: 34805 | 34 基于JPA，应该没有问题。
【在 o***i 的大作中提到】
: 有sql server支持么？
|
g*****g
发帖数: 34805 | 35 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
发帖数: 8565 | 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
发帖数: 16335 | 37 re
【在 T*******x 的大作中提到】
: 也需要connection.close()才能put connection back to pool吧？
|
w**z
发帖数: 8232 | 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
发帖数: 9224 | 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
发帖数: 24 | 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
发帖数: 8232 | 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.
|
