我在測驗持久化背景關系的機制時發現了一個奇怪的現象。
會員物體
@Entity
@Getter
@Setter
public class Member {
protected Member() {}
@Id @GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
private String username;
public Member(String username) {
this.username = username;
}
}
服務方式
@Transactional
public void addMember(String username) {
// create
Member member = new Member(username);
memberRepository.save(member);
// read
Member actual = memberRepository.findById(member.getId()).get();
log.info("Same Entity ? : {}", member == actual);
// update
String newUsername = "kitty";
member.setUsername(newUsername);
memberRepository.save(member);
// update verify
actual = memberRepository.findById(member.getId()).get();
log.info("Same Username ? : {}", member.getUsername().equals(actual.getUsername()));
// delete
memberRepository.delete(actual);
actual = memberRepository.findById(member.getId()).orElse(null);
log.info("Entity is null ? : {}", actual);
}
我認為在呼叫DELETE之前PC（Persistence Context）上有一個物體，并且DB也包含資料。
呼叫 DELETE 時，FLUSH 不會立即作業，所以我理解 DB 仍然有資料，并且在 DELETE 呼叫后從 PC（持久性背景關系）中洗掉它。
如果您在該狀態下再次呼叫 findById，PC(Persistence Context) 沒有物體，因此您必須從 DB 獲取它。
為什么從 Actual 回傳 null？
這是日志
IDE 日志
uj5u.com熱心網友回復：
如果您在該狀態下再次呼叫 findById，PC(Persistence Context) 沒有物體，因此您必須從 DB 獲取它。
這取決于FlushModeType. 默認是AUTO，這意味著 Hibernate 使用 PersistenceContext 來獲取洗掉后的物體。
如果你想從資料庫中讀取它，你必須使用COMMIT.
示例如何將它與查詢一起使用。
Member fromDB = em.createQuery("select m from Member m where m.id = :id", Member.class)
.setParameter("id", actual.getId())
.setFlushMode(FlushModeType.COMMIT)
.getSingleResult();
您可以FlushModeType.COMMIT在 Hibernate 檔案中找到所有相關資訊：https : //docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#flushing-commit
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/358243.html