-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: hibernate feasibility
PostPosted: Wed Mar 08, 2006 1:09 am 
Regular
Regular

Joined: Tue Dec 14, 2004 5:21 am
Posts: 104
Location: india
Hibernate version:3.1.2

hi all, even though i've been using hibernate for sometime, i never tried on the performance ,stability and mainly scalability issues of hibernate .

Can anyone explain about the feasibiliy of using hibernate on a highly database centric mission critical application which may involve a thousand tables ? And what if the data that is handled is highly sensitive and need concurrent access? A possible example , say an application on financial domain like electronic fund transfer, core banking systems ..etc or an
ERP system ...

please give me suggestions from your experiences ..

_________________
sHeRiN
thanks for your ratings ...... :)


Top
 Profile  
 
 Post subject: some use H with 600 tables
PostPosted: Wed Mar 08, 2006 1:38 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Thousand tables will cause slow startup time because Hibernate needs to parse and enhance bytecode for thousands of classes. Other than that H does not do any magic and its performance is OK but of course depends heavily on the way the mapping files are written.
I would expect that for database with such a big schema and presumably great deal of data in it I would expect a need for DB specific or case specific optimization where you might need to resort to straight SQL. Which Hibernate supports but you may find better support for heavy SQL use in frameworks like iBatis.
The question of concurrency is important one, but Hibernate does not do any magic here: it does what you would most likely to do anyway. And again for heavy use of DB specific features you might need to use SQL.

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 3:52 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
"..may find better support for heavy SQL use in frameworks like iBatis"

could you please elaborate that in details ? (what do we not support besides of in/out for stored procedures)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject: old question
PostPosted: Wed Mar 08, 2006 4:23 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Please see this thread where you have asked the same question and I have answered it:

http://forum.hibernate.org/viewtopic.ph ... ght=ibatis

I would add that H does not maps result set to an arbitrary classes by properties and requires a constructor that would take all the arguments, very inconvenient for more than 4 arguments...

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 4:28 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
ah yes, that old thread but alot has changed since then...i would like a fresh update ;)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject: really
PostPosted: Wed Mar 08, 2006 4:36 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Well, than I did not notice that any of my bullets were addressed.
Links please?

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 4:58 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
a. for scalars it requires declaring them;

no true anymore. we auto detect it now.

b. does not support conditional queries ie. Depending on condition there might be different ORDER by or WHERE clauses used;

Same answer as last time + one could create this as an "addon"
(last time answer: true, might be usefull - also in context of HQL queries; but very few actually asked for it and it complexify the cachability of the query.)

c. does not map to Map by default;

when i get my hands free I want to add this support to 3.2 - but patches very welcome ;)

d. does not support reusing of named mappings (column to class-property maps )

not true anymore as said in the thread.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject: thaanks
PostPosted: Wed Mar 08, 2006 5:36 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Thanks Max,
Quote:
a. for scalars it requires declaring them;
no true anymore. we auto detect it now.

Then update documentation please:
http://www.hibernate.org/hib_docs/v3/re ... medqueries
Quote:
A named SQL query may return a scalar value. You must declare the column alias and Hibernate type using the <return-scalar> element:


How about my last addition: using setters to populate arbitrary classes (do NOT require constructor) from HQL or SQL result sets?

Anyway I do not think that Hibernate should incorporate all kind features iBatis has exactly because reasons you have hinted: complexities for caching, relationships tracing etc. etc. etc. Hibernate in my opinion is getting more and more bloated with unnecessary features like XML sessions and auto generation of DB schema. Hibernate is loosing targeted approach that caused it to become so successful.

In my opinion there are situations where Hibernate is clear winner and situations where iBatis is more appropriate. That is why I suggest in certain cases to use both.

Just let it be this way, enough is enough, scope creep is very dangerous thing. Bash does not try to include awk and sed but allow using them easily. This principle makes Unix systems shine and it used to serve Hibernate well, because of the targeted approach Hibernate won against JDO and EJB....

OK, enough ranting, I wish you good luck and be stuck to common sense

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 5:50 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
well we are definitly not adding features we don't find usefull or not needed ;)

Having "property based injection" of beans instead of "constructor based" is something I find usefull and wanted to add for a while.

btw. auto creation of schemas have been in there for ages..e.g. hibernate 0.9 ;)

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject: 2c
PostPosted: Wed Mar 08, 2006 6:05 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Quote:
btw. auto creation of schemas have been in there for ages..e.g. hibernate 0.9 ;)


and I consider it as evil for aeons :)

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 6:13 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
hehe yes, people think it should not be reviewed by a DBA before used in production; but for ease of use/testing it is Good.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject: matter of opinion
PostPosted: Wed Mar 08, 2006 6:20 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
max wrote:
but for ease of use/testing it is Good.


Disagree: it is good for quick and dirty testing but not that good for real thing when all the constraints, triggers and indexes should be in place. I would say that auto generation of DB schema promotes sloppiness, but many people disagree with me :)

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 6:26 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 6:10 am
Posts: 8615
Location: Neuchatel, Switzerland (Danish)
yes - quick and dirty testing is what it should be used for.

I would hate if we had to write all the needed DDL for all db's by hand to perform hibernate unit testing.

_________________
Max
Don't forget to rate


Top
 Profile  
 
 Post subject: hmm
PostPosted: Wed Mar 08, 2006 7:00 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Too bad, writing SQL manually especially for unit tests would significantly improve their quality.

By the way in my H tests I do create DDL and test data scripts manually and that is not that big of a deal.

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject:
PostPosted: Wed Mar 08, 2006 11:11 pm 
Regular
Regular

Joined: Tue Dec 14, 2004 5:21 am
Posts: 104
Location: india
thanks for the reply guys . but i didnt really get a conclusion :)

_________________
sHeRiN
thanks for your ratings ...... :)


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 18 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.