Precisely what I was about to say in a few minutes..Peter, you read my mind..
It is not about HIbernate being slow or the software having issues of redundancy. The problem is how we implement Hibernate..That said, we need to understand how we are handlinig the xml file defnitions and relationship mappings.. Till now, we have seen instances when functional design leads to code level design. This is the case where the opposite holds true also..You have to map according to the platform - a bit of reverse engineering - and then decide the optimum performance.. large sites using cache databases is not new..Plenty of them do that - especially in lotus notes application..The problem is the data that you are trying to update... Are we doing that correctly.. Let us not blame Hibernate for everuything friends..There is more than what meets the eye.. Regardsm, jd On Wed, Jul 14, 2010 at 6:00 PM, Peter Becker <[email protected]>wrote: > On 14/07/10 21:22, Moandji Ezana wrote: > > On Wed, Jul 14, 2010 at 11:45 AM, Peter Becker > <[email protected]>wrote: > >> On 14/07/10 19:16, Moandji Ezana wrote: >> >>> The thing I find most useful about Hibernate is that when you have a lot >>> of tables of inter-related data, it really alleviates the pain of having to >>> think about what data you need to load for each possible workflow. >>> >> Not if you care about scalability, in which case you really need to know >> what you want to fetch and how all your caching layers work (although the >> caching as such can be a good feature to have). Particularly if you reach >> the same object from different contexts with different requirements, >> thinking about eager and lazy fetching can get rather complicated. > > > True, but if you need to scale massively, you probably aren't using > Hibernate anyway. (Or are you? Anyone know of massive sites that use > Hibernate?) > > I'm not talking about the Googles or Amazons. To get into this type of > problem you really need only a few gigs, if you do really stupid things only > a couple of megs will do -- if you reload all of your DB on every request > performance will degrade very fast. > > I haven't seen whole DBs being loaded yet, but I have seen things pretty > close to that -- particularly in cases where eager fetching is used as the > solution to the problem of the view not being part of the Hibernate session. > I know the answer is to expand the session lifecycle to contain the view, > but that awareness doesn't seem widely spread. Depending on your framework > it is also often not trivial. Spring can do it declaratively and knowing the > right hooks most other frameworks let you do it, but you left the realm of > nice and easy that Hibernate advocates tend to advertise. > > My point really is that while Hibernate can produce nice and easy > solutions, the only way to know you have a good solution is to fully > understand what's happening. And that is not easy and sometimes not nice > either (did someone mention "object identity" yet?). That makes Hibernate a > solution that is nice and easy as long as you either don't care at all about > the potential issues or you have someone else to take care. If you are the > one who has to care you really need a very good understanding of the OO > side, the RDB side and the ORM part. > > Peter > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
