Is Hibernate less effective in some environments, like a polygot company where several distributed systems are accessing the same db? If Acme Company has a python website reading from and writing to the same database as a java web app (web services), will Hibernate be a poor choice for the java web services app? In other words, does Hibernate caching and session management assume all db transactions for Acme will be using Hibernate? Do I need to be sensitive to certain ORM concerns at a company where several programming languages are writing a lot of updates to the same data concurrently? Is Hibernate more advantageous for a strict java shop using a java ee app server for nearly all of its business operations?
Hibernate does have some performance overhead over pure JDBC, but if you're using it cautiously it should be fine for most of use cases.
Hibernate does not assume that it handles all operations itself. The only thing I would worry about is second level cache if you need it. You won't have a way to keep it in sync if other apps access the same DB (but you don't have to use it).
Having said that, I must add that having multiple apps write to the same DB is not a good practice. I'd rather create one app that handles this DB and have others communicate with this one - this way it's much easier to keep the database consistent.
Today I've found some interesting library - ActiveJDBC. It provides RoR-like ActiveRecord interface, and I'm thinking on Hibernate replacement, but there is a question - can ActiveJDBC handle really big queries and results and is it clever to use it instead of Hibernate in any application?
I'm a developer of ActiveJDBC, so take my advice with a grain of salt :). I have not performed extensive performance comparison tests, but simple tests (storing and reading tens of thousands of records) revealed that ActiveJDBC is about twice as slow as JDBC, and Hibernate is about twice as slow as ActiveJDBC, which makes Hibernate about 4 times slower than plain JDBC. Overall, ActiveJDBC is a lot thinner than Hibernate, that was the idea for developing it. Please see this blog: Just how thin can a framework be? ActiveJDBC vs Hibernate.
Hibernate is architecturally built with client/server model in mind in the 90s (sessions, lazy loading, object graphs. etc.), while ActiveJDBC was built in 2009 primarily for request/response of modern web applications and uses a pass-through model. Depending on your logic, data and database optimizations, your mileage will vary, but I'm confident that ActiveJDBC will almost certainly be faster.
Mubin pointed out the fact that you will need migrations. I'd say this is partly correct. Migrations system is always a good idea, but ActiveJDBC does not care how tables were created, as long as they exist.
cheers
I am building a web application using JSF 2.0 tomcat 7.0.20 and a MySQL DB, My application is for a small company actully starting its business.
Now I see that there is Many implementations of JPA 2.0, now in my Case which one would be the most suitable ? or should I use pure JPA 2.0 and create my own implementation?
I want somting that would work best for the company now and wouldn't make trouble when it grows in the future, i was considering Hibernate or do you have another suggestion?
The following former questions will give you some insight about the pro and cons for each JPA implementation, and choose the one which is the best for your company.
https://stackoverflow.com/questions/2569522/hibernate-or-eclipselink
JPA 2.0 Implementations comparison : Hibernate 3.5 vs EclipseLink 2 vs OpenJPA 2
I believe that Hibernate is actually more popular nowadays, and many industries are using Hibernate.
Depends how you want to judge "most suitable" ... license? most users? fewer known bugs?. Most used doesn't necessarily mean most reliable, but then it can mean there are more people who understand its problem areas and how to avoid them. All would likely do the job for many applications, though some have long-standing issues. DataNucleus JPA is another choice for you to consider, providing for all that you need there but also allowing much more flexibility than others in terms of input and in terms of which datastores you can persist to, should these be factors in your application.
I want to develop my project on Google App Engine with Struts2. For the database I have two options JPA and JDO. Will you guys please suggest me on it? Both are new for me and I need to learn them. So I will be focused on one after your replies.
Thanks.
The GAE/J google group has several posts about this very thing. I'd do a search on there and look at people's opinions. You will get a very different message to the opinions expressed above. Also focus on the fact that BigTable is not an RDBMS. Use the right tool for the job
JPA is Sun's standard for persistence, JDO is IMHO dying (actually, it's dead but still moving). In other words, JPA seems to be a better investment on the long term. So I guess I'd choose JPA if both were new to me.
Just saw this comparison between JPA and JDO by DataNucleus themselves:-
http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html
An eye-opener.
I'm a happy user of JDO. Keep up the good work guys.
People claiming JDO is dead is not without merit. Here is what I read in the book Pro EJB 3 Java Persistence API: "Shortly thereafter Sun announced that JDO would be reduced to specification maintenance mode and that the Java Persistence API would draw from both JDO and the other persistence vendors and become the single supported standard going forward.". The author Mike Keith is the co-specification leader on EJB3. Of course he is a big supporter of JPA, but I doubt he is biased enough to lie.
It is true that when the book was published, most major vendors were united behind JPA rather than JDO, even though JDO does have more advanced technical features than JPA. It is not surprising because big players in the EE world such as IBM/Oracle are also big RDBMS vendors. More customers are using RDMBS than non-RDMBS in their projects. JDO was dying until GAE gave it a big boost. It makes sense because GAE data store is not relational database. Some JPA features does not work with bigtable such as aggregation queries, Join queries, owned many-to-many relationships. BTW, GAE supports JDO 2.3 while only support JPA 1.0. I will recommend JDO if GAE is your target cloud platform.
For the record, it is Google App Engine (GAE), so we play with the Google rules not with the Oracle/Sun rules.
Under it, JPA is not suitable for GAE, it is unstable and it does not work as expected. Neither Google is willing to support it but the bare minimum.
And for other part, JDO is quite stable in GAE and it is (in some extend) well documented by Google.
However, Google does not recommend any of them.
http://code.google.com/appengine/docs/java/datastore/overview.html
Low-level API will give the best performance and GAE is all about performance.
http://gaejava.appspot.com/
For example, add 10 entity
Python :68ms
JDO :378ms
Java Native :30ms
In race between JDO vs JPA I can only agree with the datanucleus posters.
First of all, and also most importantly, the posters of datanucleus know what they are doing. They are after all developing a persistent library and are familiar with data models other than the relational, e.g. Big Table. I am sure that id a developer for hibernate were here, he would have say: "all our assumptions when building our core libraries are tightly coupled to relational model, hibernate is not optimized for GAE".
Secondly, JPA is unquestionably in more widespread use, being a part of the official Java EE stack helps a bit, but that does not necessarily mean that it is better.
In fact, JDO, if you read about it, corresponds to a higher level of abstraction than JPA. JPA is tightly coupled to the RDBMS data model.
From a programming stand point, using the JDO APIs is a much better option, because you are conceptually compromising a lot less. You can switch, theoretically to any data model of your desire, provided the provider you use supports the underlying database.
(In practice you rarely achieve such a high level of transparancy, because you will find yourself setting your primary keys on GAE's object and you will be tying yourself to a specific database provider, e.g. google). it will still be easier to migrate though.
Thirdly, you can use Hibernate, Eclipse Link, and even spring with GAE. Google seems to have made a big effort to allow you to use the frameworks you are used to building your applications on. But what people realize when they build their GAE applications as if they were running on RDBMS is that they are slow. Spring on GAE is SLOW. You can google Google IO videos on this topic to see that it is true.
Also, adhering to standards is a good sensible thing to do, in principle I applaud. On the other hand, JPA being part of the Java EE stack makes people, at times, lose their notion of options.
Realize, if you will, that Java Server Faces is also part of the Java EE stack. And it is an unbelievably tidy solution for web GUI development. But in the end, why do people, the smarter people if I may say so, deviate from this standard and use GWT instead?
In all of this, I have to sate that there is one very significant thing going for JPA. That is Guice and its convenient support for JPA. Seems that google was not as smart as usual in this point and are content, for now in not supporting JDO. I still think that they can afford it, and eventually Guice will engulf JDO as well,... or maybe not.
Go JDO. Even if you don't have experience in it, it is not hard to pick up, and you will have a new skill under your belt!
What I think is terrible about using JDO at the time of writing this is that the only implementation vendor is Datanucleus and the drawbacks of that is the lack of competition which leads to numerous issues like:
A not very detailed documentation about some aspects like extensions
You usually get sarcastic responses from the authors like (Have you checked the logs ? May be there is a reason for having them) and annoying responses like that
You don't get an answer to your question in a helpful amount of time, sometimes if you get an answer in less than 7 days, you should consider your self lucky, even here on StackOverflow
I'm always hoping for someone to start implementing the JDO specification themselves, may be then they'll offer something more and hopefully more free attention to the community and not always bothering about being paid for support, not saying that Datanucleus authors only care about commercial support, but I'm just saying.
I personally consider Datanucleus authors has no obligation whatsoever to Datanucleus itself nor it's community. They can drop the whole project at anytime and no one can judge them for it, it's their effort and their own property. But you should know what you are getting into. You see, when one of us developers look for a framework to use, you cannot punish or command the framework's author, but on the other hand, you need your work done ! If you had time to write that framework, why would you look for one in the first place ?!
On the other hand, JDO itself has some complications like objects life cycle and stuff which isn't very intuitive and common (I think).
Edit: Now I know also JPA enforces the object life cycle mechanism, so it looks like its inevitable to deal with persisted entities life cycle states if you wish to use a standard ORM API (i.e. JPA or JDO)
What I like most about JDO is the ability to work with ANY database management system without considerable effort.
GAE/J is slated to add MYSQL before the end of the year.
JPA is the way to go as it seems to be pushed as a standardized API and has recently got momentum in EJB3.0.. JDO seems to have lost the steam.
Neither!
Use Objectify, because is cheaper (use less resources) and is faster.
FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html
Objectify is a Java data access API specifically designed for the
Google App Engine datastore. It occupies a "middle ground"; easier to
use and more transparent than JDO or JPA, but significantly more
convenient than the Low-Level API. Objectify is designed to make
novices immediately productive yet also expose the full power of the
GAE datastore.
Objectify lets you persist, retrieve, delete, and query your own typed objects.
#Entity
class Car {
#Id String vin; // Can be Long, long, or String
String color;
}
ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);
I are using EJB 3 on a fairly large J2EE project, by default with Netbeans sets the persistent provider for the entity beans to TopLink. There is the option to change the provider to one of the following or even add a new persistence library:
Hibernate
KODO
OpenJPA
Which persistence provider do you prefer to use? What are the benefits of using the another provider?
While TopLink seems to be good, I can't find much good documentation on how to control caching etc. Any help would be much appreciated.
Theres only two JPA providers I'd consider using:
If you want to stick to standard JPA I'd use EclipseLink. Whereas Toplink Essentials is the reference implementation of JPA 1.0, EclipseLink basically inherited the TopLink Essentials code and will be the reference implementation of JPA 2.0 (and bundled with Glassfish V3 when it ships; expected around JavaOne in May 2009). TopLink Essentials was a somewhat crippled version of Oracle's commercial TopLink product but EclipseLink basically has all the features TopLink has.
The other choice is obviously Hibernate. Its widely used and mature but is not issue free from what I've seen. For example, last I looked Hibernate has issues with an entity having multiple one-to-many eager relationships. I don't know if Hibernate has an equivalent to EclipseLink's batch query hint, but its an incredibly useful feature to deal with this kind of problem.
Hibernate of course also supports standard JPA. The biggest advantage of Hibernate is that if you have question about how it works a google search is likely to find you an answer.
I honestly wouldn't consider anything other than the above two providers.
I would strongly recommend Hibernate for the following reasons:
The most widely used and respected open source persistence layer in the Java world; huge active community and lots of use in high volume mission critical applications.
You don't tie yourself to J2EE or a specific vendor at all should you wish to go a different route with the rest of your application, such as Spring, etc, as Hibernate will still play nice.
I've found Hibernate to be fairly well documented, and well supported by the various caching technologies. I've also used it quite a bit more than the others in non-JPA contexts, so perhaps I'm a bit biased towards it because of that.
The few little toy projects that I've tried with TopLink Essentials worked out pretty well also, but I never got into caching or anything that would require provider specific documentation. In general, I think there's less community support for that, which is part of why I end up using Hibernate.
I use Hibernate. It's very mature and works very nicely. I personally haven't used any of the others, but I do know that Hibernate is one of the most fully featured JPA providers out there. Also because so many people are using it, just about every problem I've had with it, I can quickly find an solution with a little bit of googling.
I recently worked on a large enterprise application built with Kodo JPA framework. The SQLs produced by Kodo were generally not very scalable with large amount of data. In my opinion it produced too many queries with outer joins. Considering how many mappings we had to change when trying to scale kodo, I would not recommend using it for a large enterprise application. Even the Oracle representatives we talked to are trying to wean customers away from kodo onto TopLink. Oracle may phase out kodo in the future.
DataNucleus http://www.datanucleus.org is also a fully-compliant JPA provider, with JPA1 and some preview JPA2 features