持久性上下文缓存id和SQL查询? [英] Persistence context cache the id and SQL query?

查看:85
本文介绍了持久性上下文缓存id和SQL查询?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果有人调用 session.save(customerObject),那么将 no 插入到customer ...查询到数据库中。 Hibernate将设置id属性(sequence或Increment生成器)并将实体绑定到持久化上下文。当 transaction.commit()被调用时,持久化上下文与数据库同步。

Q:Hibernate将设置id属性?

问:在与db同步之前,持久化上下文是否会将sql查询插入到客户中?我的意思是,什么时候生成sql(在做save​​或session.flush / tx.commit时)



编辑:我从 https://forum.hibernate.org/viewtopic.php?t=951275&highlight=difference% 20persist%20save



persist()已定义良好。它使持久的瞬态实例。但是,它不保证标识符值将立即分配给持久实例,分配可能发生在刷新时间。该规范没有说明,这是我用persist()所遇到的问题。


$ b persist()还保证它不会执行INSERT语句称为事务边界之外。这对于长时间的会话和持久化上下文的对话很有用。



像persist()这样的方法是必需的。



save()不保证相同,它返回一个标识符,如果必须执行INSERT以获取标识符(例如identity生成器,而不是sequence),则会发生此INSERT立即,不管你是否在事务内部或外部。这不适合与扩展的会话/持久化上下文进行长时间对话。



这更令人困惑

解决方案

一般而言,Hibernate会尝试尽可能最新地写入数据库,而不会影响正确性该程序,并尊重它提供的方法的合同。



由于 save()记录为分配给已保存的实体一个ID并返回这个ID,当 save()被调用时它会生成ID并返回它。这可能意味着该实体是否写入数据库,具体取决于ID生成策略。
$ b 由于 persist()不能保证标识符在被调用时被分配,所以你不能在调用 persist()之后指望要分配的ID。而且你不能指望实体被写入数据库,因为这不是 persist()所做的。这很简单。



写入数据库只保证在刷新会话时执行,在提交之前自动执行,或者明确地在 flush()被调用。如果您执行的查询结果可能取决于待处理的写入,那么您还可以保证执行对数据库的写入。


If one call session.save(customerObject) then there is no insert into customer… query into the database. Hibernate will set the id property ("sequence" or "Increment" generator) and bind the entity to a persistence context. The persistence context is synchronized with the database when transaction.commit() is called.
Q: where will Hibernate set the id property?
Q: will the persistence context cache the sql query insert into customer… before synchronized with db ? I mean,when does sql generated(while doing save or session.flush/tx.commit)

EDIT: I got below from https://forum.hibernate.org/viewtopic.php?t=951275&highlight=difference%20persist%20save

persist() is well defined. It makes a transient instance persistent. However, it doesn't guarantee that the identifier value will be assigned to the persistent instance immediately, the assignment might happen at flush time. The spec doesn't say that, which is the problem I have with persist().

persist() also guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries. This is useful in long-running conversations with an extended Session/persistence context.

A method like persist() is required.

save() does not guarantee the same, it returns an identifier, and if an INSERT has to be executed to get the identifier (e.g. "identity" generator, not "sequence"), this INSERT happens immediately, no matter if you are inside or outside of a transaction. This is not good in a long-running conversation with an extended Session/persistence context.

This is more confusing

解决方案

In general, Hibernate tries to write to the database as latest as possible, without compromising the correctness of the program, and by respecting the contract of the methods it offers.

Since save() is documented to assign an ID to the saved entity and return this ID, it generates the ID when save() is called, and returns it. This might mean that the entity is written to the DB or not, depending on the ID generation strategy.

Since persist() doesn't guarantee that an identifier is assigned when it's called, then you can't count on an ID to be assigned after persist() has been called. And you can't expect the entity to be written to the DB either, since that's not what persist() does. It's as simple as that.

Writes to the DB are only guaranteed to be executed when the session is flushed, automatically before the commit, or explicitely when flush() is called. You also have the guarantee that a write to the DB is executed if you execute a query whose results might depend on the pending writes.

这篇关于持久性上下文缓存id和SQL查询?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆