hibernate是否默认使用PreparedStatement [英] Does hibernate use PreparedStatement by default
问题描述
如果是这样，那么休眠缓存编译查询在哪里，数据库驱动程序缓存它们。
我阅读了c3p0。如果hibernate默认缓存PreparedStatement，那么c3p0中的hibernate.c3p0.max_statements有什么用处。
如果hibernate默认不这样做，那么连接池必须用于缓存已准备好的语句。
有人可以澄清这些。
缓存准备语句只在特定JDBC连接的范围内才有意义。所以，当一种连接池可用于ORM层时，您只会从缓存准备好的语句中获得一些东西。否则，每次创建Hibernate会话时（通常情况下效率都不是很高），您会得到一个新的物理JDBC连接。没有任何连接池缓存准备语句仅在单个JDBC连接/ Hibernate会话的范围内有用。发生这种情况是因为没有任何连接池，物理连接实际上是关闭的，并且不会被重用 - 而是总是会在需要时使用数据库驱动程序创建新连接。
您需要考虑的另一件事是，在单个JDBC连接上打开准备语句的数量是有限的（限制因供应商而异，而据我所知，这些限制因驱动程序实现而异）。因此，在池式连接场景中，池化实现可能需要知道每个池的物理底层JDBC连接上可以维护多少个打开预备语句。可能的话，最少使用的准备好的语句首先被关闭策略被实现，但这是我自己的纯粹推测。我希望这是有道理的。每当我提到一个物理JDBC连接时，我的意思是一个实际上与数据库的新TCP / IP连接。连接池获得的连接通常会装饰/包装物理连接池。
编辑以更直接地回答您的问题：
Hibernate最有可能使用和缓存PreparedStatements（这是非常基本的JDBC优化）。问题是这种缓存发生在由物理或池提供的JDBC连接创建的语句上。如果没有池缓存，PreparedStatements只会优化在特定Hibernate Session范围内两次使用特定PreparedStatement的应用程序执行部分。通过一个池，相同的PreparedStatement将被（有效）用于跨越很多Hibernate Session实例，这些实例恰好会使用相同的基础物理连接。
$ b
属性hibernate.c3p0 .hibernate配置的.max_statements很可能会配置C3PO池实例（我确信它会自动为您创建），并且此配置与打开预准备语句数量受物理限制的事实有关， JDBC连接。
"Hibernate always uses PreparedStatement for calls to the database" Quoted here. If so then where does hibernate cache compiled queries, does DB driver cache them.
I read about c3p0. If hibernate caches PreparedStatement by default then what is the use of hibernate.c3p0.max_statements in c3p0. If hibernate does not do it by default then is connection pooling mandatory for caching prepared statements.
Could somebody please clarify these.
Caching prepared statements only makes sense in the scope of a specific JDBC connection. So, you will only gain something out of caching prepared statements when a sort of connection pooling is available to the ORM layer. Otherwise, you get a new "physical" JDBC connection every time you create a Hibernate Session (which is not very efficient normally). Without any connection pooling caching prepared statements is only useful in the scope of a single JDBC connection / Hibernate Session. This happens because without any connection pooling the "physical" connection is actually closed and won't be reused - instead always a new connection will be created using the database driver, whenever it is required.
One other thing that you need to take into account, is that the number of open prepared statements on a single JDBC connection is limited (the limitation is vendor dependent and varies between driver implementations as far as I know). So, in a pooled connections scenario, the pooling implementation will likely need to know how many open prepared statements may be maintained on each of the pool's "physical" underlying JDBC connections. Likely, a "least used prepared statements gets closed first" policy is implemented, but this is pure speculation on my part.
I hope this makes some sense. Whenever I mention a "physical" JDBC connection I mean an actually new TCP/IP connection to the database. Connections obtained by a connection pool will typically decorate/wrap a "physical" one.
Edits to answer your questions more directly:
Hibernate most likely uses and caches PreparedStatements (this is very basic JDBC optimization). The question is does this caching happen on the statements created by a "physical" or a pool provided JDBC connection. Without a pool caching the PreparedStatements only optimizes the part of the application execution that uses a specific PreparedStatement twice in the scope of a specific Hibernate Session. With a pool the same PreparedStatement will (effectively) be used across many Hibernate Session instances that will happen to use the same underlying "physical" connection.
The property hibernate.c3p0.max_statements of your hibernate configuration will most likely configure the C3PO pool instance (which I am pretty sure is created automatically for you) and this configuration has something to do with the fact about the number of open prepared statements being limited in a "physical" JDBC connection.
这篇关于hibernate是否默认使用PreparedStatement的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
