对Flush原理的个人理解

PS：听了尚学堂老师的课自己总结的，有错误的地方欢迎大家指正。

1. 看一下session的结构。

l Session中有一个actionQueue队列，其中有几个对象比如Insertions,deletetions等等。当执行完save（），delete（）等操作之后，就把想要执行sql对象放在相应的对象中。

l Session中还有一个persistenceContext，相当于缓存。在这之中有一个entityEntries,经过几层目录之后，发现还有一份sql执行对象，也就是说当session.save（）等操作之后，实际上把要执行sql的对象放在了两个地方。其中有个不同，在entityEntries中的，有个标识exsistsInDatebase，查看数据库中有无记录。

2. Flush工作原理：

l 当执行flush之后，首先到actionQueue中，将要发出的sql语句发出，然后将actionQueue中与之对应的映射清空。然后到persistenceContext中，将exsistsInDatebase设置为true。要想把缓存清空需要调用evict()方法或者clear()方法。

l 补充：如果先save(),再evict()，最后commit()，会出现问题。因为evict()，把缓存清空了，但是当执行commit()的时候会显示的调用flush方法，发现在映射中存在，需要发出sql语句，但是需要在persistenceContext中找到与之对应的对象，并将exsistsInDatebase设置为true的时候发现对象没了，所以会报错。所以save()之后flush()一下就没问题了。

3. 关于Hibernate主键生成策略。

l 主键生成策略采用的是uuid，调用完成save后，只是将user纳入到了session的管理不会发出insert语句，但是id已经生成，session中existsInDatebase状态为false。

l 主键生成策略采用的是asign，同上不会发出insert语句。

l 主键生成策略为native,调用session.save后，将执行insert语句，返回有数据库生成的id，纳入了session的管理，修改了session中existsInDatebase状态为true。如果数据库的隔离级别设置为为提交读，那么我们可以看到save过的数据。