ORM其实有两个方面,一个是静态的mapping,也就是结构化的关系。一个对象与一张或者多张表怎么样对应。
还有一个方面就是动态关系。在应用中创建,查询,修改一些对象的时候,这些变化如何同步到到DB里面去,反过来,
DB的数据如果变了,怎么样反映到应用中的对象中来。换句话说,是内存中的对象是如何与DB里面的数据同步的。
关于如何mapping,使用hibernate的人都应该懂得,只是另一个动态的方面,初学者不重视,也不在意。不过会经常遇到一些问题,
抱怨hibernate复杂。我今天就和大家分享一下我的学习和理解。
首先理解一个概念,持久化上下文(persistence context),也就是一种缓存。它会记住app对object的更改,
择机同步到DB里面去。还有一个概念是持久化管理器(persistence manager),Session,通过它来操作对象,改变对象
与持久化上下文的关系。
持久化上下文(persistence context)
你可以把它看成是一级缓存,他缓存了所有的持久化对象。在Hibernate中每一个Session都有一个内部的持久化上下文。
你也许看不到它,你也不需要手动的开启它,实际上他默认而且必须被开启。但他帮你做了很多事情。
1. 变更检查以及后写入。既然是缓存就会发生被缓存的对象snapshot和DB不一致。因为不是所有的对象都变过,Hibernate就有
一定的策略帮你找到变更过的对象,在适当的时候,通常是事务comment的时候更新到DB。见到数据库的压力。同样,在一个事务
中,你也许对某一个对象做了很多次改变,Hibernate会在事务结束的时候合并变化一次更新,这就是后写入。这样可以减少对DB
的lock时间。
2. 提供一级缓存,这样,当你要查询一个对象的时候,它会先在cache里面找,有就返回。这样就不用hit DB了。好处你懂得。
3. 保证java 对象标识。在同一个context里面,如果你对一个row查两次,context保证你只有一个对象产生,这样就保证只有一个
对象与row对应。不会产生冲突,也节约内存。
4. Hibernate 可以帮你把这个context扩展到一个用户会话。尤其是在web应用时,很有用。
■ Hibernate can do automatic dirty checking and transactional write-behind.
■ Hibernate can use the persistence context as a first-level cache.
■ Hibernate can guarantee a scope of Java object identity.
■ Hibernate can extend the persistence context to span a whole conversation.
尽管如此,你也得善待持久化上下文。既然是缓存,就耗费内存,如果你无所顾忌的在一个事务中load大量不用的对象,就会内存溢出。
持久化上下文和数据库同步也就是Flushing的时机如下
■ When a Transaction on the Hibernate API is committed
■ Before a query is executed
■ When the application calls session.flush() explicitly
第二点特别注意,如果你不注意,查一句,改一句,查一句,再改一句,hibernate会不停的flush。performance就会有问题。
下面看看再Hibernate的概念中,对象的不同状态:Transient objects,Persistent objects, Removed objects 还有Detached objects。
有了持久化上下文(context)的概念以后,就好理解这四种状态了。Transient objects就是你刚刚创建(new),这时候context不知道有
她,当然也不会管它。一旦你save了它,Hibernate就把它放到context里面cache起来,也就是Persistent objects了。这时候对他的修改会在
事务flush的时候同步到DB里面去。如果你从DB里面load一个对象出来,它也是Persistent objects,但是如果你delete它,它就会被hibernate再flush的
时候从DB里面删除。在这之前是Removed objects,这种对象你最好不要再用它,也不要有对他的引用,因为它就是一个即将被删除的对象。对于一个Persistent object,
如果Session关闭了,自然也就没有人管了,他就是Detached objects。我感觉Detached objects和Transient objects也没有什么本质的区别。表面上看大概Transient objects
里面有db id,但Transient object里面没有。对于Removed objects,当Session关闭后也就变成Transient object,因为它和DB里面的数据没有关系。Detached objects虽然没有
人管,但是实际上它和DB里面的某个row关联。
关于Detached objects多说一点
因为人们经常会用这样的对象,比如你用DAO查出来以后返回到service或UI层。context关闭了,很正常也很必要。需要注意的是,如果你要对
这些对象执行euqals方法的时候,你要从写它的equals核和hashCode方法。尤其是你要用HashSet来存它的时候。因为如果你在一个新的context里面再load一个
和这个Detached object对应的同一条row的对象时,他们不是指向同一个对象引用,这样很危险,容易冲突。前面说了,只有再同一个context里面,hibernate才
帮你保证同一对象引用一个row。其实他是靠db id来判断的。Detached object可不一定都有db id,也许你后面修改了呢,db不知道。在实现equals方法的时候,也不要
用db id来比,最好用bussiness key,也就是业务上唯一的一组属性。
再说一下get和load方法的区别
1. load不会查询db,而是返回一个proxy。get会查询db。
2. 如果查不到,load会报ObjectNotFoundException。get会返回null。
load方法很有用,有很多时候你指向将他和另外一个对象关联,添加外键,这时候load就够了。这类情况很能改进performance。hibernate只在用到对象id以外属性的时候,
采取查db。
还有一个方面就是动态关系。在应用中创建,查询,修改一些对象的时候,这些变化如何同步到到DB里面去,反过来,
DB的数据如果变了,怎么样反映到应用中的对象中来。换句话说,是内存中的对象是如何与DB里面的数据同步的。
关于如何mapping,使用hibernate的人都应该懂得,只是另一个动态的方面,初学者不重视,也不在意。不过会经常遇到一些问题,
抱怨hibernate复杂。我今天就和大家分享一下我的学习和理解。
首先理解一个概念,持久化上下文(persistence context),也就是一种缓存。它会记住app对object的更改,
择机同步到DB里面去。还有一个概念是持久化管理器(persistence manager),Session,通过它来操作对象,改变对象
与持久化上下文的关系。
持久化上下文(persistence context)
你可以把它看成是一级缓存,他缓存了所有的持久化对象。在Hibernate中每一个Session都有一个内部的持久化上下文。
你也许看不到它,你也不需要手动的开启它,实际上他默认而且必须被开启。但他帮你做了很多事情。
1. 变更检查以及后写入。既然是缓存就会发生被缓存的对象snapshot和DB不一致。因为不是所有的对象都变过,Hibernate就有
一定的策略帮你找到变更过的对象,在适当的时候,通常是事务comment的时候更新到DB。见到数据库的压力。同样,在一个事务
中,你也许对某一个对象做了很多次改变,Hibernate会在事务结束的时候合并变化一次更新,这就是后写入。这样可以减少对DB
的lock时间。
2. 提供一级缓存,这样,当你要查询一个对象的时候,它会先在cache里面找,有就返回。这样就不用hit DB了。好处你懂得。
3. 保证java 对象标识。在同一个context里面,如果你对一个row查两次,context保证你只有一个对象产生,这样就保证只有一个
对象与row对应。不会产生冲突,也节约内存。
4. Hibernate 可以帮你把这个context扩展到一个用户会话。尤其是在web应用时,很有用。
■ Hibernate can do automatic dirty checking and transactional write-behind.
■ Hibernate can use the persistence context as a first-level cache.
■ Hibernate can guarantee a scope of Java object identity.
■ Hibernate can extend the persistence context to span a whole conversation.
尽管如此,你也得善待持久化上下文。既然是缓存,就耗费内存,如果你无所顾忌的在一个事务中load大量不用的对象,就会内存溢出。
持久化上下文和数据库同步也就是Flushing的时机如下
■ When a Transaction on the Hibernate API is committed
■ Before a query is executed
■ When the application calls session.flush() explicitly
第二点特别注意,如果你不注意,查一句,改一句,查一句,再改一句,hibernate会不停的flush。performance就会有问题。
下面看看再Hibernate的概念中,对象的不同状态:Transient objects,Persistent objects, Removed objects 还有Detached objects。
有了持久化上下文(context)的概念以后,就好理解这四种状态了。Transient objects就是你刚刚创建(new),这时候context不知道有
她,当然也不会管它。一旦你save了它,Hibernate就把它放到context里面cache起来,也就是Persistent objects了。这时候对他的修改会在
事务flush的时候同步到DB里面去。如果你从DB里面load一个对象出来,它也是Persistent objects,但是如果你delete它,它就会被hibernate再flush的
时候从DB里面删除。在这之前是Removed objects,这种对象你最好不要再用它,也不要有对他的引用,因为它就是一个即将被删除的对象。对于一个Persistent object,
如果Session关闭了,自然也就没有人管了,他就是Detached objects。我感觉Detached objects和Transient objects也没有什么本质的区别。表面上看大概Transient objects
里面有db id,但Transient object里面没有。对于Removed objects,当Session关闭后也就变成Transient object,因为它和DB里面的数据没有关系。Detached objects虽然没有
人管,但是实际上它和DB里面的某个row关联。
关于Detached objects多说一点
因为人们经常会用这样的对象,比如你用DAO查出来以后返回到service或UI层。context关闭了,很正常也很必要。需要注意的是,如果你要对
这些对象执行euqals方法的时候,你要从写它的equals核和hashCode方法。尤其是你要用HashSet来存它的时候。因为如果你在一个新的context里面再load一个
和这个Detached object对应的同一条row的对象时,他们不是指向同一个对象引用,这样很危险,容易冲突。前面说了,只有再同一个context里面,hibernate才
帮你保证同一对象引用一个row。其实他是靠db id来判断的。Detached object可不一定都有db id,也许你后面修改了呢,db不知道。在实现equals方法的时候,也不要
用db id来比,最好用bussiness key,也就是业务上唯一的一组属性。
再说一下get和load方法的区别
1. load不会查询db,而是返回一个proxy。get会查询db。
2. 如果查不到,load会报ObjectNotFoundException。get会返回null。
load方法很有用,有很多时候你指向将他和另外一个对象关联,添加外键,这时候load就够了。这类情况很能改进performance。hibernate只在用到对象id以外属性的时候,
采取查db。