Very interesting.
So after the read of this explanation and the architecture and coding
implication of the usage of Hibernate
my question stay the same ....
Does the ORM approach based on a relational DB is the good way ?
The usage of a Document Oriented Database seem more in adequacy with the
problem to solve.
No ?
On Thu, Jun 28, 2012 at 8:32 PM, Frank Zhang <frank.zh...@citrix.com> wrote:
> Hi David:
> I think I can answer part of your question, about graph object.
> Actually CloudStack's database entity the xxxVO you see does have
> graph object, however it's not using the typical way which is well known as
> composition (e.g VMInstance.NetworkVO.NicVO), we use id which is the
> primary key in database to composite object graph.
> Current popular ORM, Hibernate or JPA, use one-to-many,
> many-to-one, many-to-many .... or new annotation(JPA2) like
> MapKeyJoinColumn to make object graph transparent just as you mentioned.
> However, this doesn't fit CloudStack's requirement in terms of huge number
> of objects.
> ORM offers to two ways to fetch relational object: eagerly
> of lazy. The Eagerly mode definitely won't work for CloudStack, let me cite
> an example, assume we have a beautiful graph object hierarchy:
> HostVO
> |___ VMInstanceVO[]
> |_________NicVO[]
>
> Now once you get a HostVO, you can transparently browse vms
> running on it and even get nic information of VM. However, it doesn't work.
> Let's say you have 10000 hosts, each host run 10 ~ `50 VMs, each VM has 1
> ~ 3 nics. With eager fetching, a listAllHost operation is going to blow up
> memory, there are half millions object loaded in memory and most of them
> are useless.
>
> Lazy mode seemingly resolve this problem, however, Hibernate
> and JPA only allow lazy load when your entity is still in persistence
> context, according to their saying, the object must be attached. This
> works pretty well in tradition web application, open the persistence
> context when request comes in and close it when request finishes. However,
> in CloudStack, a request like DeployVM is made up of multiple operations
> such as preparing storage, preparing network ... some of these operations
> (e.g. preparing storage) are long run, it's impossible to keep a
> persistence opening so long. And most of operations are based on theadpool
> where persistence context is hard to propagate because it's based on
> threadlocal.
> Well, one solution is recommended by hibernate, using detach to remove
> entity from persistence and attach it back when needs. IMO, this is a quite
> annoying way that brings much trouble to programmer. Let's say I write a
> function receiving an entity as parameter:
> Void printHost(HostVO vo) {
> printVMsonHost(vo.vms)
> }
> Can somebody tell me the HostVO is attached or detached now?
> no one knows. You have to call some function of persistence to judge if
> the HostVO is attached, if not, attach it back. Otherwise you will be
> greeted by a EntityIsNotManaged exception. It ends up with you have to do
> boring judge/attach at everywhere you play with entity object because you
> don't know if it is attached. Ok, even we don't mind it, the attach
> operation is quite annoying. JPA/Hibernate has a method "detach" entity,
> but they don't have the opposite method to 'attach' an entity. Simply
> google "jpa attach", there are tons of questions about proper way to
> re-attach an object back to persistence. The usual way is to call merge(),
> but it has the side effect that if you change the entity accidentally, your
> change would be written to database, this is the source of mysterious bug.
>
> In CloudStack, you can use id(the primary key of relational
> object) to fetch your composition on demand, though it's not as intuitive
> as directly wiring whole relational object in code, it does its job well in
> practice.
>
> > -----Original Message-----
> > From: David Avenante [mailto:d.avena...@gmail.com]
> > Sent: Thursday, June 28, 2012 4:24 PM
> > To: cloudstack-dev@incubator.apache.org
> > Subject: Re: Hibernate
> >
> > Ok I try ;)
> >
> > As far I can see in the code the majority of the Object have no
> relations and
> > are simple VO
> >
> > Many of object use IMHO a bad pattern (DTO, VO ...)
> >
> > For example :
> >
> > public class UserVmVO extends VMInstanceVO implements UserVm { ...
> >
> > There is NO relation between objects. Object are State.
> > *The power of Hibernate is to try for the user to make transparent the
> > management of a graph object* *There is NO graph object in Cloudstack as
> > far I can see.*
> > *
> > *
> > *In the other side I think the Business Domain of the System Management
> is
> > more document oriented.* *For exemple a VM can be represented by a
> > simple JSON structure:*
> > *
> > *
> > *{*
> > * name: "myVM",*
> > * memory: 1024*
> > * network: [{eth0: 195.21.24.12}, {eth1: 12.35.15.28}**]*
> > * storage: [{local: [{sdb ....}]}]*
> > *}*
> > *
> > *
> > *The force of the approach is to have a schema less support. If we need
> to
> > add attribute to a VM no need to migrate de DB.* *In many case some part
> > of the document can be exposed in JSON format directly to the view (UI).*
> > *
> > *
> > *We have used MongoDB in on of my project (we used hibernate before)
> > and the return in term of usage in very very good.* *In many many case,
> see
> > the data as document is a big win.*
> > *
> > *
> > *
> > *
> >
> >
> >
> >
> > On Thu, Jun 28, 2012 at 5:53 PM, Kevin Kluge <kevin.kl...@citrix.com>
> > wrote:
> >
> > > Rajesh, can you provide some rationale for this choice versus other
> > > options.
> > >
> > > -kevin
> > >
> > > > -----Original Message-----
> > > > From: Rajesh Battala [mailto:rajesh.batt...@citrix.com]
> > > > Sent: Wednesday, June 27, 2012 10:44 PM
> > > > To: cloudstack-dev@incubator.apache.org
> > > > Subject: RE: Hibernate
> > > >
> > > > Hi,
> > > >
> > > > I had started working on this issue. As Hibernate is LGPL we cannot
> > > > use
> > > this in
> > > > our Apache repo.
> > > > I had discussed with Chiradeep and Kelven.
> > > >
> > > > Am looking at replace Hibernate with Spring Framework
> > > > simpleJDBCTemplate.
> > > >
> > > > The Spring Framework is released under version 2.0 of the Apache
> > > > License http://www.springsource.org/spring-framework
> > > >
> > > > Thanks
> > > > Rajesh Battala
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> > > > > Sent: Thursday, June 28, 2012 10:45 AM
> > > > > To: cloudstack-dev@incubator.apache.org
> > > > > Cc: cloudstack-dev@incubator.apache.org
> > > > > Subject: Re: Hibernate
> > > > >
> > > > > The ORM in the AWS module is 90% used by S3.
> > > > > The dependency is mostly abstracted by a DAO layer; there is
> > > > > another dependency on transactions. I believe Rajesh B is already
> > > > > working on this aspect and there is a bug open on it.
> > > > >
> > > > > --
> > > > > Chiradeep
> > > > >
> > > > > On Jun 27, 2012, at 21:52, "David Nalley" <da...@gnsa.us> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Jun 28, 2012, at 12:45 AM, Sheng Liang
> > > > > > <sheng.li...@citrix.com>
> > > > > wrote:
> > > > > >
> > > > > >>> In short, I see three options (please comment if you see more)
> 1.
> > > > > >>> Rip out
> > > > > hibernate and replace with some other ORM 2. Make the AWS API bits
> > > > > an optional non-default part of the build.
> > > > > >> 3. Declare that hibernate is a system requirement for
> > > > > >> CloudStack
> > > > > >>
> > > > > >> I prefer option #1. It is the cleanest. I don't think it will
> > > > > >> be very difficult to
> > > > > rip out Hibernate.
> > > > > >>
> > > > > >> Sheng
> > > > > >
> > > > > >
> > > > > >
> > > > > > That is my personal inclination as well, though I am somewhat
> > > > > > reticent to
> > > > > say so, since I am not doing any of the work to rip and replace.
> > > > > At the same time choice of ORM is a big issue. I know, for
> > > > > instance that Alex was looking into finding another ORM for the
> rest of
> > CloudStack.
> > > > > When I initially looked at the Hibernate issue, Prachi told me she
> > > > > thought it was about 2 weeks worth of work.
> > > > > >
> > > > > >
> > > > > > --David
> > >
>
