"Gavin King is the founder of the Hibernate project, a object/relational mapping framework for Java. Currently, he works full time in the project, paid by the JBoss Group. In this exclusive interview to JavaFree, Gavin talks about his entering in the JBoss Group, and the Hibernate Project, what's new in version 3 and the integration of the framework with the new features of Java 5."
Gavin answered questions as these:
- How do you see other ORM tools like OJB, JDO and Toplink? Do you evaluate or spend time looking at feature of those products? Why people would choose Hibernate?
- How do you see alternatives to relational databases, like XML and OO databases, or Prevayler?
- Could you tell us about what's new in Hibernate 3, and the benefits these changes will bring to users?
Take a look: Interview with Gavin King
-
Interview with Gavin King on Hibernate 3 (97 messages)
- Posted by: Vitor Fernando Pamplona
- Posted on: November 04 2004 13:52 EST
Threaded Messages (97)
- Interview with Gavin King on Hibernate 3 by graham o'regan on November 04 2004 15:52 EST
- Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 15:59 EST
-
Interview with Gavin King on Hibernate 3 by graham o'regan on November 04 2004 04:42 EST
-
Interview with Gavin King on Hibernate 3 by Max Andersen on November 04 2004 05:33 EST
-
enhancements to hbm2ddl by Holger Engels on November 05 2004 03:05 EST
-
enhancements to hbm2ddl by Max Andersen on November 05 2004 08:29 EST
-
enhancements to hbm2ddl by Holger Engels on November 06 2004 03:58 EST
- enhancements to hbm2ddl by Umesh Sharma on December 27 2005 08:48 EST
-
enhancements to hbm2ddl by Holger Engels on November 06 2004 03:58 EST
-
enhancements to hbm2ddl by Max Andersen on November 05 2004 08:29 EST
-
enhancements to hbm2ddl by Holger Engels on November 05 2004 03:05 EST
-
Interview with Gavin King on Hibernate 3 by Max Andersen on November 04 2004 05:33 EST
-
Interview with Gavin King on Hibernate 3 by graham o'regan on November 04 2004 04:42 EST
- Interview with Gavin King on Hibernate 3 by Max Andersen on November 04 2004 17:36 EST
- Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 15:59 EST
- docs by Serge Boulay on November 04 2004 16:35 EST
- docs by Christian Bauer on November 04 2004 16:56 EST
- Interview with Gavin King on Hibernate 3 by han theman on November 04 2004 16:52 EST
- Interview with Gavin King on Hibernate 3 by Steve Zara on November 04 2004 17:28 EST
-
Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 05:41 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 04:17 EST
-
Interview with Gavin King on Hibernate 3 by Max Andersen on November 05 2004 08:21 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 09:04 EST
-
Attitude by Donald Diego on November 05 2004 10:41 EST
- Attitude by Steve Zara on November 05 2004 11:16 EST
-
Interview with Gavin King on Hibernate 3 by Juozas Baliuka on November 05 2004 10:48 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 11:11 EST
- Interview with Gavin King on Hibernate 3 by Juozas Baliuka on November 05 2004 11:39 EST
- Interview with Gavin King on Hibernate 3 by Erik Gollot on November 06 2004 05:39 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 11:11 EST
-
Attitude by Donald Diego on November 05 2004 10:41 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 09:04 EST
-
Interview with Gavin King on Hibernate 3 by Max Andersen on November 05 2004 08:21 EST
- Hibernate features by Ales Justin on November 06 2004 05:02 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 04:17 EST
-
hibernate vendors by Christian Sell on November 04 2004 05:47 EST
-
hibernate vendors by Steve Zara on November 05 2004 04:20 EST
-
hibernate vendors by Erik Gollot on November 05 2004 10:34 EST
- hibernate vendors by Steve Zara on November 05 2004 11:06 EST
-
hibernate vendors by Erik Gollot on November 05 2004 10:34 EST
-
hibernate vendors by Steve Zara on November 05 2004 04:20 EST
-
Interview with Gavin King on Hibernate 3 by Andrew Hayes on November 04 2004 05:48 EST
-
Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 05:53 EST
- Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 05:53 EST
-
Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 05:53 EST
-
Interview with Gavin King on Hibernate 3 by Max Andersen on November 05 2004 07:58 EST
-
Interview with Gavin King on Hibernate 3 by Haris Peco on November 05 2004 08:32 EST
-
Interview with Gavin King on Hibernate 3 by Emmanuel Bernard on November 05 2004 12:15 EST
- Interview with Gavin King on Hibernate 3 by Haris Peco on November 05 2004 04:57 EST
-
Interview with Gavin King on Hibernate 3 by Max Andersen on November 05 2004 04:49 EST
- Interview with Gavin King on Hibernate 3 by Christian Bauer on November 05 2004 07:07 EST
-
Interview with Gavin King on Hibernate 3 by Emmanuel Bernard on November 05 2004 12:15 EST
-
Interview with Gavin King on Hibernate 3 by Haris Peco on November 05 2004 08:32 EST
-
Interview with Gavin King on Hibernate 3 by Christian Bauer on November 04 2004 05:41 EST
- Interview with Gavin King on Hibernate 3 by Ronald Tetsuo Miura on November 04 2004 20:07 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 06:28 EST
- Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 06:30 EST
-
Interview with Gavin King on Hibernate 3 by Emmanuel Bernard on November 05 2004 12:08 EST
- Interview with Gavin King on Hibernate 3 by Steve Zara on November 08 2004 09:07 EST
-
Interview with Gavin King on Hibernate 3 by Steve Zara on November 05 2004 06:28 EST
- Interview with Gavin King on Hibernate 3 by Steve Zara on November 04 2004 17:28 EST
- Interview with Gavin King on Hibernate 3 by Dan Winfield on November 05 2004 03:25 EST
- Hibernate vs. IBatis by Alessandro Santini on November 05 2004 04:17 EST
- Hibernate vs. IBatis by Emmanuel Bernard on November 05 2004 12:03 EST
- Hibernate vs. IBatis by Alessandro Santini on November 05 2004 04:17 EST
- What's in OR? Take a look at iBatis. by Wolfgang Gehner on November 05 2004 05:14 EST
- JDO,EJB3 and Hibernate all have space to prosper by Santosh Panda on November 05 2004 06:40 EST
- JDO,EJB3 and Hibernate all have space to prosper by Vania Cilli on November 05 2004 07:01 EST
- JDO,EJB3 and Hibernate all have space to prosper by Steve Zara on November 05 2004 07:26 EST
- JDO,EJB3 and Hibernate all have space to prosper by Steve Zara on November 05 2004 07:29 EST
-
JDO,EJB3 and Hibernate all have space to prosper by Santosh Panda on November 05 2004 08:52 EST
-
JDO,EJB3 and Hibernate all have space to prosper by Steve Zara on November 05 2004 09:06 EST
-
JDO,EJB3 and Hibernate all have space to prosper by Max Andersen on November 05 2004 09:13 EST
- JDO,EJB3 and Hibernate all have space to prosper by Steve Zara on November 05 2004 09:43 EST
-
JDO,EJB3 and Hibernate all have space to prosper by Max Andersen on November 05 2004 09:13 EST
-
JDO,EJB3 and Hibernate all have space to prosper by Steve Zara on November 05 2004 09:06 EST
-
JDO,EJB3 and Hibernate all have space to prosper by Santosh Panda on November 05 2004 08:52 EST
- JDO,EJB3 and Hibernate all have space to prosper by Vania Cilli on November 05 2004 07:01 EST
- Dumb question. by Dave Minter on November 05 2004 08:25 EST
- To clarify... by Dave Minter on November 05 2004 08:32 EST
- Dumb question. by Max Andersen on November 05 2004 08:34 EST
-
Uh... by Dave Minter on November 05 2004 08:41 EST
-
And another thing... by Dave Minter on November 05 2004 08:43 EST
- And another thing... by Max Andersen on November 05 2004 09:16 EST
-
Uh... by Vic Cekvenich on November 05 2004 08:53 EST
-
Maybe... by Dave Minter on November 05 2004 08:58 EST
- iBATIS + Stored Procs by Scott Severtson on November 05 2004 03:09 EST
-
Maybe... by Dave Minter on November 05 2004 08:58 EST
-
Uh... by Max Andersen on November 05 2004 09:34 EST
-
Uh... by Dave Minter on November 05 2004 09:48 EST
- Uh... by Max Andersen on November 05 2004 05:04 EST
-
Uh... by Dave Minter on November 05 2004 09:48 EST
-
And another thing... by Dave Minter on November 05 2004 08:43 EST
-
Uh... by Dave Minter on November 05 2004 08:41 EST
- attitude by thoff thoff on November 05 2004 10:42 EST
- attitude by Emmanuel Bernard on November 05 2004 12:23 EST
-
Daily dose of irony by Donald Smith on November 05 2004 12:59 EST
- Daily dose of irony by Juozas Baliuka on November 05 2004 01:44 EST
- Daily dose of irony by Emmanuel Bernard on November 05 2004 03:09 EST
-
attitude by thoff thoff on November 05 2004 04:41 EST
-
attitude by Max Andersen on November 05 2004 05:12 EST
-
attitude by thoff thoff on November 05 2004 05:34 EST
-
Second level cache ? by Vagif Verdi on November 05 2004 11:37 EST
-
Second level cache ? by thoff thoff on November 06 2004 12:44 EST
-
Second level cache ? by Juozas Baliuka on November 06 2004 01:21 EST
-
Second level cache ? by thoff thoff on November 06 2004 10:51 EST
-
Second level cache ? by Juozas Baliuka on November 06 2004 11:26 EST
- Second level cache ? by thoff thoff on November 06 2004 11:58 EST
-
Second level cache ? by Max Andersen on November 06 2004 11:37 EST
-
Second level cache ? by thoff thoff on November 06 2004 12:00 EST
-
Second level cache ? by Emmanuel Bernard on November 06 2004 12:21 EST
-
Second level cache ? by thoff thoff on November 06 2004 01:02 EST
-
Second level cache ? by Juozas Baliuka on November 06 2004 01:31 EST
-
Second level cache ? by Cameron Purdy on November 07 2004 06:25 EST
- Second level cache ? by Juozas Baliuka on November 08 2004 12:52 EST
-
Second level cache ? by Cameron Purdy on November 07 2004 06:25 EST
- Second level cache ? by Christian Bauer on November 06 2004 01:40 EST
-
Second level cache ? by Dmitry Zemnitskiy on November 08 2004 10:01 EST
- Second level cache ? by Christian Bauer on November 08 2004 10:35 EST
-
Second level cache ? by Juozas Baliuka on November 06 2004 01:31 EST
-
Second level cache ? by thoff thoff on November 06 2004 01:02 EST
- Second level cache ? by Juozas Baliuka on November 06 2004 12:48 EST
-
Second level cache ? by Emmanuel Bernard on November 06 2004 12:21 EST
-
Second level cache ? by thoff thoff on November 06 2004 12:00 EST
-
Second level cache ? by Juozas Baliuka on November 06 2004 11:26 EST
-
Second level cache ? by thoff thoff on November 06 2004 10:51 EST
-
Second level cache ? by Max Andersen on November 06 2004 02:42 EST
- Second level cache ? by Juozas Baliuka on November 06 2004 03:23 EST
-
Second level cache ? by Juozas Baliuka on November 06 2004 01:21 EST
-
Second level cache ? by thoff thoff on November 06 2004 12:44 EST
- attitude by Max Andersen on November 06 2004 02:38 EST
-
Second level cache ? by Vagif Verdi on November 05 2004 11:37 EST
-
attitude by thoff thoff on November 05 2004 05:34 EST
-
attitude by Max Andersen on November 05 2004 05:12 EST
-
Daily dose of irony by Donald Smith on November 05 2004 12:59 EST
- attitude by Max Andersen on November 05 2004 16:57 EST
- attitude by Emmanuel Bernard on November 05 2004 12:23 EST
- JDO - the coolest underdog in town by geoff hendrey on November 05 2004 14:15 EST
- The future of annotations by Yann Perrin on November 11 2004 16:33 EST
-
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: graham o'regan
- Posted on: November 04 2004 15:52 EST
- in response to Vitor Fernando Pamplona
On the road map, hibernate 3 is due in q1 of next year, are the developers still on target for that release date? Is there a more specific date available. In particular, the ability to hand-craft SQl statements will be one of the more useful features , followed by filters ;) -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 04 2004 15:59 EST
- in response to graham o'regan
We are still on target, but unable to give an accurate date at the moment.
Hibernate3 is actually almost feature complete and we are planning a beta1 release ASAP. Last time we had a beta phase of 4 months for a major release, I would expect something similar for Hibernate3. The current quality looks good so it might be possible to have the final release earlier. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: graham o'regan
- Posted on: November 04 2004 16:42 EST
- in response to Christian Bauer
Can you elaborate on the improvements to the toolset? Are you aiming to improve the quality of hbm2sql for example, or do you intend to include something similar to middlegen (again)? -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 04 2004 17:33 EST
- in response to graham o'regan
We will post a roadmap for the toolset in the near future.
In the meanwhile I'm interested into hear what you mean by "improve hbm2sql" (hbm2sql is actually named hbm2ddl) ?
What do you see as it's problems ?
Regarding reverse engineering support (middlegen) it is one of our main interests - to have good support for starting from a database schema. -
enhancements to hbm2ddl[ Go to top ]
- Posted by: Holger Engels
- Posted on: November 05 2004 03:05 EST
- in response to Max Andersen
It should be able to create a schema update script from comparing two sets of hbm files and a given dialect .. including dropping of columns, changing the size of columns on all databases. In many cases, tables will have to be dropped and recreated, while data is backed up into a temporary table. I suppose, it's hardly possible to track cardinality changes of relations (one-to-many to many-to-many), though it would be helpful! -
enhancements to hbm2ddl[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 08:29 EST
- in response to Holger Engels
I don't think doing a diff between two mappings is the right way to go about this.
Maybe adding info from a previous mapping could probably help in making better suggestions for changes to the schema - but it should at least check the current schema which is reality/facts more than a mapping are.
It should at least be the mapping compared to the current db schema. And this is what schemaupdate does to a certain degree.
Contributions to this tool are very welcome, even though I do not think such tool can be trusted to do stuff automatically in production.
But maybe enhancing the tool to spit out suggestions for changes and allow users to choose which one to perform would be useable ? i don't know....maybe not worth the effort? -
enhancements to hbm2ddl[ Go to top ]
- Posted by: Holger Engels
- Posted on: November 06 2004 03:58 EST
- in response to Max Andersen
My company is doing automatic schema updates in production with a home grown tool. The tool is even unloading and reloading tables for certain transitions on certain databases.
of course, update scripts should be reviewed and tested, before they are applied in production. they are a part of the release. therefore the scripts can only be created by comparing two mappings. and then you're right: the assumed database structure should be compared with the actual structure before applying the scripts. -
enhancements to hbm2ddl[ Go to top ]
- Posted by: Umesh Sharma
- Posted on: December 27 2005 08:48 EST
- in response to Holger Engels
Hi Holger,
I would be interested in a tool which creates the update script by comparing old and new hbm files.
How your home grown tool is creating the upgrade script?
Is there any tool available which generates the schema upgrade script
Regards,
Umesh -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 04 2004 17:36 EST
- in response to graham o'regan
"hand crafting of sql" is already there.
look for <sql-insert>,<sql-delete>, etc. in the DTD and unit tests.
furthermore look at the Hibernate3 related entries at our blog - it mentions some of these. It is also covered a bit on the wiki - but actual code and examples are in the unit tests (which actually also has been greatly improved in the sense of being extended with more "real-life" than "out-of-this-world" scenarios :) -
docs[ Go to top ]
- Posted by: Serge Boulay
- Posted on: November 04 2004 16:35 EST
- in response to Vitor Fernando Pamplona
Any plans for docs/book to get hibernate2 users up to speed with hiberate3 ? -
docs[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 04 2004 16:56 EST
- in response to Serge Boulay
The docs are being updated at the moment (all new features will be included as well as new and longer tutorials, of course).
Hibernate in Action has been written many months ago (actually, we started almost 2 years ago!), so it naturally doesn't cover Hibernate3. I'm thinking about a second edition or something, no promises at this point. The information in the current edition is definitely valid and important for all versions of Hibernate (and ORM in general). -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: han theman
- Posted on: November 04 2004 16:52 EST
- in response to Vitor Fernando Pamplona
Gavin says JDO has no future. After using both JDO and Hibernate extensively in the past year, I actually agrees with that kinda bold statement.
Hibernate is slowly becoming a de-facto standard and that is fine with me.
Gavin's premise-less conclusion that OODBMS's are flawed is a different story. It depends on the use-case. OODBMS databases rules in quite a few contexts. I sort of like the marriage of the OODBMS and RBMS world - as provided by Matisse... best of both worlds, really (can even access it with ADO.NET and JDBC drivers, IIRC) -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 04 2004 17:28 EST
- in response to han theman
Gavin says JDO has no future. After using both JDO and Hibernate extensively in the past year, I actually agrees with that kinda bold statement.Hibernate is slowly becoming a de-facto standard and that is fine with me.
Well, major JDO vendors who are currently experiencing rapid growth would disagree with you and him. JDO 2.0 is very much equivalent to Hibernate 3 in features, but will be available both in open source and commercial systems.
Hibernate is a good system, but lacks many features that make it easily scalable for large data sets. Also, Hibernate is not a 'standard' until you can get it from more than one Vendor. JDO Vendors compete to supply high-performance systems. That is the point of a standard. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 04 2004 17:41 EST
- in response to Steve Zara
Could you name one of the features that Hibernate is missing? -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 04:17 EST
- in response to Christian Bauer
Could you name one of the features that Hibernate is missing?
This has been discussed in detail in previous TSS threads. For example, there are ways that objects are managed in caches that allow JDO to automatically flush objects to keep memory usage low. Also, in current Hibernate versions, I'll look this up in detail if this is wanted.
But there is also something else that I feel is missing - the right attitude! I work on very large data sets which require large transactions. I was investigating the use of Hibernate, but it did not take me long to come across advice that Hibernate is not appropriate for this sort of 'batch processing', and PL/SQL should be used instead: There would be all kinds of memory problems. I tried a JDO implementation and there were memory problems too, but after some help from the vendor, these disappeared and I had a high performance portable solution. I know I probably could have used Hibernate, but I didn't think it was wise to use a product that said it was bad at doing this! I think Hibernate has a long way to go to convince corporate developers of its scalability and usefulness in large systems, which is where JDO vendors are making considerable amounts of money. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 08:21 EST
- in response to Steve Zara
I'm starting to get very offended by this "right attitude" problem ;)
#1 last time this issue was raised I showed that I/we had actually listend and fixed other issues concerning large scale batching. (People (including me) are actually using hibernate to do large scale processing)
#2 last time I also explained that what we said about large scale processing was that ORM's (including hibernate and jdo and whatever) are NOT the best tool for this if you want the best performance. I did not hear you prove me wrong on that point.
#3 buildtime enhancement does provide an edge when it comes automatic memory management, and the Hibernate Team actually talked about ways to do similar stuff with respect to avoiding the possible OutOfMemory errors when doing large scale batch processing....but it turned out that if we tried to do this we could/would hurt other currently very performant areas. So we judged that our current solution works fine for large scale batch processing if you just follow some rules (which you should do anyway when doing large scale batch processing) (http://blog.hibernate.org/cgi-bin/blosxom.cgi/Gavin%20King/batch.html)
...and please remember that NO tool can solve ALL problems, so either remove some problems or add some tools when needed ;) -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 09:04 EST
- in response to Max Andersen
I'm starting to get very offended by this "right attitude" problem ;)
I have no intention to offend, and I apologise if I did. Its just that I have seen some comments made by Hibernate people that definitely discouraged me from using it (see below)#1 last time this issue was raised I showed that I/we had actually listend and fixed other issues concerning large scale batching. (People (including me) are actually using hibernate to do large scale processing)#2 last time I also explained that what we said about large scale processing was that ORM's (including hibernate and jdo and whatever) are NOT the best tool for this if you want the best performance. I did not hear you prove me wrong on that point.
I don't press for performance - I aim for portability. I gladly sacrifice a degree of performance if it results in a standards-compliant cross-platform application. But that's just my attitude!#3 buildtime enhancement does provide an edge when it comes automatic memory management, and the Hibernate Team actually talked about ways to do similar stuff with respect to avoiding the possible OutOfMemory errors when doing large scale batch processing....but it turned out that if we tried to do this we could/would hurt other currently very performant areas.
This is the thing about standards. Many JDO people definitely disagree about the advantage of buildtime enhancement. With JDO 2.0, the enhancement method is up the the vendor, So I can first write my code, then pick and choose between vendors - I can choose the most effective implementation.So we judged that our current solution works fine for large scale batch processing if you just follow some rules (which you should do anyway when doing large scale batch processing) (http://blog.hibernate.org/cgi-bin/blosxom.cgi/Gavin%20King/batch.html)...and please remember that NO tool can solve ALL problems, so either remove some problems or add some tools when needed ;)
You see - it's quotes like that blog entry (and the comments in the replies) that are exactly what I mean.
Suppose I want to use an ORM for an application with large transactions ('batch processing' as you call it). Do I go for a JDO product where the vendor encourages its use (and has good examples of how JDO works well at this), or do I go for a product where one of the key developers says that he is 'very skeptical that Java is the right place to do [this]', and that he and colleagues have to 'swallow our pride' and accept that people want to do this. It may be admirable honesty, but it's hardly the way to encourage commercial developers working on critical applications to use the product. I was skeptical anyway that using a non-standard ORM API was the right way to proceed, but when I saw that blog entry, it made my mind up. -
Attitude[ Go to top ]
- Posted by: Donald Diego
- Posted on: November 05 2004 10:41 EST
- in response to Steve Zara
You see - it's quotes like that blog entry (and the comments in the replies) that are exactly what I mean. Suppose I want to use an ORM for an application with large transactions ('batch processing' as you call it). Do I go for a JDO product where the vendor encourages its use (and has good examples of how JDO works well at this), or do I go for a product where one of the key developers says that he is 'very skeptical that Java is the right place to do [this]', and that he and colleagues have to 'swallow our pride' and accept that people want to do this. It may be admirable honesty, but it's hardly the way to encourage commercial developers working on critical applications to use the product. I was skeptical anyway that using a non-standard ORM API was the right way to proceed, but when I saw that blog entry, it made my mind up.
I agree. A lot of the JBoss and related projects (Hibernate, jBPM, etc) have the attitude that:
"we are smarter than everyone else, and this is the way you should do it. If you don't do it this way, then you are wrong. Ok, if you *really* want to do it this way, here's a workaround, but trust us it's bad. BTW - I can't believe you want to do it that way, you're lucky we let you do it. Don't be surprised if you fail."
Now maybe they really are the developers in the ivory tower that don't need to look at other competing products in the industry or analyze real project requirement (e.g. Gavin in the article says that he would "assume" most businesses have requirements like this). However, it's hard to put complete faith in someone else without them knowing your particular situation. For this reason, it is much better to support flexible use of the product and just post guidelines for using it.
Of course, this is a bit of an exaggeration, but I think you can understand the point. -
Attitude[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 11:16 EST
- in response to Donald Diego
I agree. A lot of the JBoss and related projects (Hibernate, jBPM, etc) have the attitude that:"we are smarter than everyone else, and this is the way you should do it. If you don't do it this way, then you are wrong. Ok, if you *really* want to do it this way, here's a workaround, but trust us it's bad. BTW - I can't believe you want to do it that way, you're lucky we let you do it. Don't be surprised if you fail.
You have summed this up perfectly! I think this puts off a lot of people. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 05 2004 10:48 EST
- in response to Steve Zara
So, you get to know JDO is the best O/R mapping solution and this blog helped you to decide, as result you have performant and very portable, standards-compliant cross-platform batch processing application. Hibernate team is honest and doe's not sell crap as you can see in this blog, are you sure JDO vendors do not sell standards-compliant crap for you ? -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 11:11 EST
- in response to Juozas Baliuka
are you sure JDO vendors do not sell standards-compliant crap for you ?
Yes, because what they sell me works, and works well (so far). -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 05 2004 11:39 EST
- in response to Steve Zara
I am very glad if it helps.are you sure JDO vendors do not sell standards-compliant crap for you ?
Yes, because what they sell me works, and works well (so far). -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Erik Gollot
- Posted on: November 06 2004 05:39 EST
- in response to Steve Zara
As I said, the problem is that an object model is appropriate in a context and perhaps not in another. The problem is/can not be between object vs. PL/SQL, the problem is that in another context, PL/SQL is more appropriate for the processing you've to do (for performance problem or memory footprint).
What I'm trying to explain is one of the big problem of OODBMS ie the datas, in a IS, are used by many applications that need their own vision of theses datas. This is why RDBMS are really more appropriate. With an object oriented view of a RDBMS, you necessarely facing the same problem. But it's not serious, that it is !! -
Hibernate features[ Go to top ]
- Posted by: Ales Justin
- Posted on: November 06 2004 05:02 EST
- in response to Christian Bauer
How is Hibernate handling locking on MSSQL DB (its lock hints)? -
hibernate vendors[ Go to top ]
- Posted by: Christian Sell
- Posted on: November 04 2004 17:47 EST
- in response to Steve Zara
Also, Hibernate is not a 'standard' until you can get it from more than one Vendor. JDO Vendors compete to supply high-performance systems. That is the point of a standard.
you have hibernate "vendors" (i.e. companies that offer hibernate know-how or support) on every corner. And all their ideas, and of anyone else using it, flow together to improve the product. I think that is a model that should be (and has proven to be) easily able to compete with a flock of commercial vendors- and is a type of standardization in itself.
Still, I wish JDO and all those promoting it all the best. It would be sad to see it swallowed up by EJB 3.
Christian -
hibernate vendors[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 04:20 EST
- in response to Christian Sell
Also, Hibernate is not a 'standard' until you can get it from more than one Vendor. JDO Vendors compete to supply high-performance systems. That is the point of a standard.
you have hibernate "vendors" (i.e. companies that offer hibernate know-how or support) on every corner. And all their ideas, and of anyone else using it, flow together to improve the product. I think that is a model that should be (and has proven to be) easily able to compete with a flock of commercial vendors- and is a type of standardization in itself.
I see what you are saying, but I strongly disagree. You can't turn to a competing Hibernate vendor and say 'I need speed improvements else I will switch to another supplier'. Competition comes at the level of implementors, not supporters.Still, I wish JDO and all those promoting it all the best. It would be sad to see it swallowed up by EJB 3.Christian
I don't think it will - there is so much money invested in it, and a large number of users. -
hibernate vendors[ Go to top ]
- Posted by: Erik Gollot
- Posted on: November 05 2004 10:34 EST
- in response to Steve Zara
Your problem is not a linked to the incapacity of Hibernate or any other ORM to do the job. You're just facing the fact that for some processings, an object oriented view of the problem is not appropriate.
You often have this problem with some applications that are object oriented for their front part, objects and ORM are a good solution here, but that have a back-end part with a lot of "batch" processing. Batch process are often orthogonals to your object model; so using objects is not necessarly appropriate and inefficient. For these batch processes you need to work with another object model or "simply" with stored procedures and denormalization -
hibernate vendors[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 11:06 EST
- in response to Erik Gollot
Your problem is not a linked to the incapacity of Hibernate or any other ORM to do the job. You're just facing the fact that for some processings, an object oriented view of the problem is not appropriate.
I'll give you an example. Large areas of a database need to be frequently re-loaded from either external databases or other data sources, and much if not all of this re-loading needs to be in a single transaction so it can be rolled back in case of a fault. The database is accessed by an ORM, so it makes sense to use the ORM as the mechanism to load the data. The loading procedure may involve several passes through the data, in which relationships between objects (rows) are established, and which (in my real example) may involve hundreds of thousands of objects (rows).
Now, I could write much of this as stored procedures, but I don't. I consider it very bad software engineering practise to have the structure and relationships of my objects coded at two places: Java and PL/SQL - it makes code hard to maintain and port. I could write it all in PL/SQL, but that would be very bad for portability - a key requirement of my application. So, its all object-oriented and in Java, and this makes sense, at least to me. I don't think mixing object-oriented and non-object-based views of the same data in the same application is good design. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Andrew Hayes
- Posted on: November 04 2004 17:48 EST
- in response to Steve Zara
Gavin says JDO has no future. [snip]
Well, major JDO vendors who are currently experiencing rapid growth would disagree with you and him. [snip]
Apologies to the JDO group, but a more-interesting comparison than Hibernate3 <-> JDO2 is Hibernate3 <-> EJB3.
Has anyone done a (coherent) compare/contrast paper?
Regards,
Andrew. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 04 2004 17:53 EST
- in response to Andrew Hayes
As mentioned by Gavin in the interview, Hibernate3 is a superset of EJB3. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 04 2004 17:53 EST
- in response to Christian Bauer
Oops, of EJB3 _persistence_. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 07:58 EST
- in response to Steve Zara
"Hibernate is a good system..."
thank you ;)
"..., but lacks many features that make it easily scalable for large data sets"
Which ones ? (besides the (what i call VERY minor) missing "automatic garbage collection feature") -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Haris Peco
- Posted on: November 05 2004 08:32 EST
- in response to Max Andersen
"..., but lacks many features that make it easily scalable
> for large data sets"
> Which ones ? (besides the (what i call VERY minor) missing
> "automatic garbage collection feature")
for instance , table A have one-to-many relation to table b with > 10000 rows
Hibernate can load collection for b (lazy or direct), but load
all rows or nothing and we get out-of-memory
I know for scrollable resultset or setMaxRows, but it isn't solution for colections
regards -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 05 2004 12:15 EST
- in response to Haris Peco
for instance , table A have one-to-many relation to table b with > 10000 rowsHibernate can load collection for b (lazy or direct), but loadall rows or nothing and we get out-of-memoryI know for scrollable resultset or setMaxRows, but it isn't solution for colectionsregards
1. lazy="true" on B
2. or collection filter will do exactly what you want -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Haris Peco
- Posted on: November 05 2004 16:57 EST
- in response to Emmanuel Bernard
for instance , table A have one-to-many relation to table b with > 10000 rowsHibernate can load collection for b (lazy or direct), but loadall rows or nothing and we get out-of-memoryI know for scrollable resultset or setMaxRows, but it isn't solution for colectionsregards
1. lazy="true" on B2. or collection filter will do exactly what you want
It isn't what I want!
lazy=load don't load rows until I access, but when I access to collection hibernate load all rows in memory >10000 rows
(>10000 rows in collection is real, for instance, partner have
>10000 orders)
I want next : I set attribute maxRows=100 in mapping and I want that when I access to collection Hiberante load only 100 rows - for instance , I seek row 5000 and Hibernate load rows 4950-5049 - when I seek 5010 or 4990 now hibenrate have this in memory/cache, but whe I seek row 5500 hibernae load new 100 rows from database
Except this, I want update, add, delete row in Scrollable Results like updatable ResultSet in JDBC do
regards -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 16:49 EST
- in response to Haris Peco
We have filtered collections for doing that stuff.
We have refrained from adding support for "transparent" large collections since it requires you to somehow close the collection when you are finished with it...but put it on the jira and see what happens - no promises ;) -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 05 2004 19:07 EST
- in response to Max Andersen
We have excellent support for large collections in Hibernate, but we call them "Bags". -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Ronald Tetsuo Miura
- Posted on: November 04 2004 20:07 EST
- in response to han theman
The time for JDO to gain market has already passed. Sun never gave the support it needed. Now, with the new EJB3 spec, all I can see is a dead end to JDO. Hibernate is a excellent ORM implementation, sure, but what hindered JDO's growth wasn't Hibernate, but the lack of support from Sun. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 06:28 EST
- in response to Ronald Tetsuo Miura
The time for JDO to gain market has already passed. Sun never gave the support it needed. Now, with the new EJB3 spec, all I can see is a dead end to JDO. Hibernate is a excellent ORM implementation, sure, but what hindered JDO's growth wasn't Hibernate, but the lack of support from Sun.
This is a surprising thing to say, considering that the JDO marking is thriving. JDO is a standard, it has multivendor support, and it works with J2SE. EJB3 does not work with J2SE. There is some prospect (in a few years) of a new standard combined persistence mechanism, but that is not EJB3! -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 06:30 EST
- in response to Steve Zara
This is a surprising thing to say, considering that the JDO marking is thriving.
Sorry - marking = market -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 05 2004 12:08 EST
- in response to Steve Zara
EJB3 does not work with J2SE.
Did you read the sun annoncement saying that the EJB3 ORM part will be able to be implemented outside any container? -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 08 2004 09:07 EST
- in response to Emmanuel Bernard
EJB3 does not work with J2SE.
Did you read the sun annoncement saying that the EJB3 ORM part will be able to be implemented outside any container?
Yes, but I would not call that 'EJB'....I have been following the announcements closely. -
Interview with Gavin King on Hibernate 3[ Go to top ]
- Posted by: Dan Winfield
- Posted on: November 05 2004 03:25 EST
- in response to Vitor Fernando Pamplona
"The Hibernate3 core (currently in alpha) is the most powerful ORM engine in the world."
What exactly makes it that much better?
"Um, traditionally, no, we did not pay that much attention - I was much more comfortable being guided by request from users, than by "what the other guys got"."
I am assuming that Gavin is more enthusiastic about Hibernate than a good judge on how it compares to other ORM solutions since he clearly hasn't looked at them? -
Hibernate vs. IBatis[ Go to top ]
- Posted by: Alessandro Santini
- Posted on: November 05 2004 04:17 EST
- in response to Dan Winfield
To my personal experience, iBatis 2.0 is much lighter and delivers 99% of the features a developer looks for in a ORM framework. You can even choose what features you want to use (dao framework, sqlmaps, caching, lazy loading, etc.). We deployed it into production and we are very satisfied with that.
I compared it to Hibernate 2 (so this message might be a little offtopic). I got puzzled when I saw that Hibernate *requires* entities to have a key (has it been fixed in 3.0?) and does not allow (at least this is what I understood) more mappings for the same table. From this point of view, iBatis looks much more flexible. -
Hibernate vs. IBatis[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 05 2004 12:03 EST
- in response to Alessandro Santini
I compared it to Hibernate 2 (so this message might be a little offtopic). I got puzzled when I saw that Hibernate *requires* entities to have a key (has it been fixed in 3.0?) and does not allow (at least this is what I understood) more mappings for the same table. From this point of view, iBatis looks much more flexible.
1. entities does not require an "id" property.
2. You can map several entities on the same table. What you can't do is have 2 representations of the *same row* (DB speaking) at the *same time* in the *same session*.
If you think a little bit about that, it is hopeful for data consistency. -
What's in OR? Take a look at iBatis.[ Go to top ]
- Posted by: Wolfgang Gehner
- Posted on: November 05 2004 05:14 EST
- in response to Vitor Fernando Pamplona
"To my personal experience, iBatis 2.0 is much lighter and delivers 99% of the features a developer looks for in a ORM framework. You can even choose what features you want to use (dao framework, sqlmaps, caching, lazy loading, etc.). We deployed it into production and we are very satisfied with that."
+1
Wolfgang Gehner -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Santosh Panda
- Posted on: November 05 2004 06:40 EST
- in response to Vitor Fernando Pamplona
I dont agree that Hibernate would be the only ruler in Persistance space.
JDO would stay as lot of innovations are coming from providers like Solarmetric,OpenJDO
Also it is meant for small scale application persistance(where high performance to move to EJB is not needed)
Hibernate would compete with JDO in this space.
As Gavin says,Hibernate also would be a implementation of EJB3 spec,hence can be a ORM tool leader in both small scale and also high performance applications.
Finally whichever is part of JSR Spec,that would win customer ;) Hibernate has already aiming that with EJB3 spec.
cheers,
-Santosh Panda
www.upco.co.uk -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Vania Cilli
- Posted on: November 05 2004 07:01 EST
- in response to Santosh Panda
I dont agree that Hibernate would be the only ruler in Persistance space.JDO would stay as lot of innovations are coming from providers like Solarmetric,OpenJDOAlso it is meant for small scale application persistance(where high performance to move to EJB is not needed)Hibernate would compete with JDO in this space.As Gavin says,Hibernate also would be a implementation of EJB3 spec,hence can be a ORM tool leader in both small scale and also high performance applications.Finally whichever is part of JSR Spec,that would win customer ;) Hibernate has already aiming that with EJB3 spec.cheers,-Santosh Pandawww.upco.co.uk
When did EJB became high performant? -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 07:26 EST
- in response to Vania Cilli
When did EJB became high performant?
Since the local call feature of EJB2 -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 07:29 EST
- in response to Santosh Panda
I dont agree that Hibernate would be the only ruler in Persistance space.JDO would stay as lot of innovations are coming from providers like Solarmetric,OpenJDOAlso it is meant for small scale application persistance
I think many of the commercial JDO vendors would be very surprised to find it classified as 'meant for small scale application persistence'. On the contrary, JDO is often used for large-scale persistence situations. -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Santosh Panda
- Posted on: November 05 2004 08:52 EST
- in response to Steve Zara
Please find word "also" in the statement ;)....Also it is meant for small scale application persistance.
I agree and understand that you can use JDO for large scale applications but when EJB3 comes into effect, it would take the space for large scale. -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 09:06 EST
- in response to Santosh Panda
Please find word "also" in the statement ;)....Also it is meant for small scale application persistance.I agree and understand that you can use JDO for large scale applications but when EJB3 comes into effect, it would take the space for large scale.
Why? JDO has the advantage it can be used for BOTH standalone and J2EE applications - I would lose this benefit in switching to EJB. -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 09:13 EST
- in response to Steve Zara
shameless plug - but Hibernate has the same advantage, and the upcoming unioned persistence api will also have these advantages :) -
JDO,EJB3 and Hibernate all have space to prosper[ Go to top ]
- Posted by: Steve Zara
- Posted on: November 05 2004 09:43 EST
- in response to Max Andersen
shameless plug - but Hibernate has the same advantage, and the upcoming unioned persistence api will also have these advantages :)
This is very true. If Hibernate and JDO vendors both support the unioned api (as seems likely) this would be a very good situation. -
Dumb question.[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 05 2004 08:25 EST
- in response to Vitor Fernando Pamplona
This isn't exactly a Hibernate question, although Hibernate might be the answer...
Is there a Java persistence layer that gives me full latitude to create an arbitrary mapping between existing SQL logic and data objects?
Specifically, if I have a query:
select id,message from blog where id=?
Is there a persistence layer that allows me to cause that SQL to construct some instances of a specific object, populate the Id and Message attributes, and deal with the cacheing and transaction handling in some sane way?
The "connected" approach is tedious and error prone. Most of the persistence layers I've looked into seem to require me to mess with my data in order to achieve much. Data outlives application logic, so I don't want to make that compromise.
I'm very uninformed about my options, so maybe Hibernate 3 can already do this - but I've formed the impression that it can't. I'm all ears.
Dave. -
To clarify...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 05 2004 08:32 EST
- in response to Dave Minter
When I say "instances of a specific object", I mean instances of a specific pre-existing object, one which is at most a bean, but no more standardized (or otherwise changed to fit the persistence tool) than that.
Dave. -
Dumb question.[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 08:34 EST
- in response to Dave Minter
In H2 (and H3) this can be done for queries (look at createSQLQuery())
But remember that this is just for querying and you probably also need to do inserts/updates/deletes etc, right ?
For that you need to do some mapping of some sort :)
In H2 we generate that stuff automatically - the same in H3, but you can override it to much more detail. -
Uh...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 05 2004 08:41 EST
- in response to Max Andersen
I think we might be talking at cross purposes here - that looks rather like a function prototype, so I'm guessing there's a method called "createSQLQuery" that allows me to do arbitrary queries - rather than some mapping that I can write into my XML file that describes this.
As well as being after this sort of mapping, I'm after something that's less work than the connected approach :-)
Everything I've seen so far requires one of the following:
1. A specific DB Schema (I'm keeping my data just as it is)
2. Generated data classes (It's got to integrate with a legacy system, and what happens if I change persistence layers?)
3. More work tying the data into the classes than the connected approach
4. More work instantiating business objects out of dynamic data than the connected approach.
Dave. -
And another thing...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 05 2004 08:43 EST
- in response to Dave Minter
And why are sprocs treated in a particularly special way?
Why's it harder to map this:
select id,msg from foo where id=?
Than this ?
{getFoo(?,?,?)}
Dave. -
And another thing...[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 09:16 EST
- in response to Dave Minter
in H3 you can map sprocs by providing the stored proc sql.
(but its not perfect yet - it's a work in progress)
And now we are add it - sprocs are great, but geez the current big db vendors should try to align how they implement their JDBC API for this.... -
Uh...[ Go to top ]
- Posted by: Vic Cekvenich
- Posted on: November 05 2004 08:53 EST
- in response to Dave Minter
Dave, as to you 4 questions, many found answer in iBatis.
It's very scalable BECUASE it is E/R and SQL based.
.V -
Maybe...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 05 2004 08:58 EST
- in response to Vic Cekvenich
Looks interesting, but doesn't appear to be able to do stored procedures. -
iBATIS + Stored Procs[ Go to top ]
- Posted by: Scott Severtson
- Posted on: November 05 2004 15:09 EST
- in response to Dave Minter
iBATIS can call stored procs two different ways. If your stored proc has only input parameters and returns a resultset, you can use "EXEC sp_foo 55, 44, 33" syntax anywhere normal SQL could go in the SQL map. If you need more advanced features (output or in/out parameters, return values, etc), there is a <procedure> tag offering the full capabilities.
I'm in the midst of a project right now with iBATIS 2.0, and all DB access goes through stored procs (corporate policy, long story).
--Scott Severtson
Senior Architect
Centare Group, Ltd. -
Uh...[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 09:34 EST
- in response to Dave Minter
before i answer this one i would like to know what you mean by "connected" ?
Is it the connect the dots approach with having a externally or embedded in src code mapping describing how you would like your mapping you call "connected" ? -
Uh...[ Go to top ]
- Posted by: Dave Minter
- Posted on: November 05 2004 09:48 EST
- in response to Max Andersen
By "connected" I mean directly using a JDBC connection to access the data, and then "manually" populating the data objects and cache.
Dave. -
Uh...[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 17:04 EST
- in response to Dave Minter
So the "connected" approach is just normal jdbc ?
Regarding your listed "limitions":1. A specific DB Schema (I'm keeping my data just as it is)
H2 had certain limitations, but in H3 all of these have practically been removed so you can map whatever ;)2. Generated data classes (It's got to integrate with a legacy system, and what happens if I change persistence layers?)
H2 and H3 have always worked on existing java classes that is capable of providing data (either via propertymethods or field access)....and there is no dependency on implementing a specific class/interface.3. More work tying the data into the classes than the connected approach
well - for me I think it is much easier to write one mapping than to write the inserts/deletes/updates statements for 99% of my persistent needs.....for the remaining pct I use whatever is better4. More work instantiating business objects out of dynamic data than the connected approach.
This i don't get ? What is the difference ? If the connected approach can - then the ORM can too....that is what it does ;) -
attitude[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 05 2004 10:42 EST
- in response to Vitor Fernando Pamplona
I'm starting to get very offended by this
> "right attitude" problem ;)
When someone says your product stinks and has not future i wonder who should be offended?
My issue with hibernate is that you can't have an object in multiple simultaneous sessions in multiple threads. This really limits your threading model. -
attitude[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 05 2004 12:23 EST
- in response to thoff thoff
My issue with hibernate is that you can't have an object in multiple simultaneous sessions in multiple threads. This really limits your threading model.
???
You mean you want the *same* object instance in memory shared and modified by multiple application threads and persisted by multiple sessions. This is dangerous and pointless. -
Daily dose of irony[ Go to top ]
- Posted by: Donald Smith
- Posted on: November 05 2004 12:59 EST
- in response to Emmanuel Bernard
Someone said:A lot of the JBoss and related projects (Hibernate, jBPM, etc) have the attitude that:"we are smarter than everyone else, and this is the way you should do it. If you don't do it this way, then you are wrong. Ok, if you *really* want to do it this way, here's a workaround, but trust us it's bad. BTW - I can't believe you want to do it that way, you're lucky we let you do it. Don't be surprised if you fail.
In the same thread, Emanuel replies to a technical consideration:This is dangerous and pointless.
LOL...
- Don -
Daily dose of irony[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 05 2004 13:44 EST
- in response to Donald Smith
EJB is designed for this use case. Why do you want to replace EJB with hibernate ? -
Daily dose of irony[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 05 2004 15:09 EST
- in response to Donald Smith
Someone said:
I am not a JBoss Employee, so I probably have the right to ;-) I must confess that a little bit more detailed answer could have been more appropriate ;-)A lot of the JBoss and related projects (Hibernate, jBPM, etc) have the attitude that:"we are smarter than everyone else, and this is the way you should do it. If you don't do it this way, then you are wrong. Ok, if you *really* want to do it this way, here's a workaround, but trust us it's bad. BTW - I can't believe you want to do it that way, you're lucky we let you do it. Don't be surprised if you fail.
In the same thread, Emanuel replies to a technical consideration:This is dangerous and pointless.
LOL... - Don
Here it is
Having an object instance (JVM speaking) shared means you completly break you DB isolation level, plus allow the sessionS having it to execute the same update statement several times (1 per session)... There are lots of other weirds stuffs, I'll let you imagin them. -
attitude[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 05 2004 16:41 EST
- in response to Emmanuel Bernard
It's amazing how fast we get confirmation of this:
>I agree. A lot of the JBoss and related projects (Hibernate, >jBPM, etc) have the attitude that:"we are smarter than >everyone else, and this is the way you should do it. If you >don't do it this way, then you are wrong.
with this:
>You mean you want the *same* object instance in memory shared >and modified by multiple application threads and persisted by >multiple sessions. This is dangerous and pointless.
I don't think it's pointless at all. I want an object
to be accessible from many threads because objects don't
belong to threads.
As for dangerous, i appreciate your deep concern, but
i would like to make such decisions for myself. -
attitude[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 17:12 EST
- in response to thoff thoff
All objects can be accessed from multiple *threads* - why do you keep saying they are not ?
Regarding deciding what is dangerous then please come up with ONE usecase (you must have one ;) that says it is BETTER to let two *sessions* manipulate the persistent state of same object instance at the same time ?
If you do that you will have non-deterministic behavior for your persistence....is that ever a good thing ? :) -
attitude[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 05 2004 17:34 EST
- in response to Max Andersen
that says it is BETTER to let two *sessions* manipulate
>the persistent state of same object instance at
> the same time
Let's say i choose a stateful model where i cache
most of my objects in memory. If i have two different
threads from two different clients accessing the same
user, hibernate will give me this very frustrating
error about how it wants you to partition
threads, sessions, and objects. I think this is
quite a reasonable thing to do. Apparently though i am
living in danger. -
Second level cache ?[ Go to top ]
- Posted by: Vagif Verdi
- Posted on: November 05 2004 23:37 EST
- in response to thoff thoff
2 thoff thoff
I'm confused. Have you ever tried to use EHCache that comes with Hibernate, or plugin one og the many other second level cache libraries that are pluggable to Hibernate ?
I have no problem accessing cached objects from many many threads. And I did not see any other Hibernate user having that problem. -
Second level cache ?[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 06 2004 00:44 EST
- in response to Vagif Verdi
No, i have not ever used another level of caching.
So i guess you never get this exception:
HibernateException: Illegal attempt to associate a
collection with two open sessions.
I find that hard to believe.
And then when i went to the ever arrogant forum, i get this sweet response:
the message is quite explanatory -
Second level cache ?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 06 2004 01:21 EST
- in response to thoff thoff
Hibernate doe's not support it, is it not clear from error message ? You can not do many things with hibernate and you are warned about it, if you can not use framework for this reason then it is better not to use it. You can not have sex with hibernate and nobody recommends to do it, the same is about concurrent collection modification. -
Second level cache ?[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 06 2004 10:51 EST
- in response to Juozas Baliuka
You can not have sex with hibernate and nobody
> recommends to do it, the same is about
> concurrent collection modification.
I don't know, hibernate gets a lot of love...
> Who shall win this "race" ? Should the user be
> named "Weird Al" or "Mamma Bird" ?
I have object level locking to protect objects.
And yes, i did stop using hibernate because
i found it's session model simplistic.
Because of the other benefits of hibernate
i was disappointed. I found the attitude
mentioned early disappointing as well.
If we can't be tolerant about different
approaches to application development we
probably can't be tolerant about anything. -
Second level cache ?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 06 2004 11:26 EST
- in response to thoff thoff
I have object level locking to protect objects.And yes, i did stop using hibernate because i found it's session model simplistic.
You are right, it is simplistic. Many of developers need this simplistic for reason. I see no problems in your approaches too, EJB is designed this way and it works for many people. There is no reason to reinvent EJB. It must be clear from documentation http://www.hibernate.org/hib_docs/reference/en/html_single/#transactions-threads
Please read instructions on usage before to bame this code. -
Second level cache ?[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 06 2004 11:58 EST
- in response to Juozas Baliuka
Please read instructions on usage before to bame this code.
I didn't really blame the code. And you sound very defensive. I would dearly love to be able to read a pile of documentation, assuming such quality doc is available, and instantly realize every implication of it. But alas, i am not that clever. So i usually find surprises when actually coding.
My mental model had to expand to understand all the implications of the thread local model of resource usage which seems to be common in java frameworks. I don't like it, but now i know about it and what it means so i factor it in.
And i didn't mention EJB. They are just general programming issues. -
Second level cache ?[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 06 2004 11:37 EST
- in response to thoff thoff
We tolerate any kind of development, but a piece of software cannot! (at least not without either making it too generic or too errorprone)
We make the database do the locking...because that is what it is build for ;) (+ object level locking is much harder to make efficient both for users and frameworks...but that's just my experience/opinion)
It sounds very much like you have built certain parts of a persistence solution your self - so use whatever fits under that...i'm keen to hear what you have used instead...I guess raw jdbc ? -
Second level cache ?[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 06 2004 12:00 EST
- in response to Max Andersen
We make the database do the locking
Then you are fine with a stateless model where objects are activated/passivated for each use. I don't like using a database as RAM, but that's just me. -
Second level cache ?[ Go to top ]
- Posted by: Emmanuel Bernard
- Posted on: November 06 2004 12:21 EST
- in response to thoff thoff
We make the database do the locking
Then you are fine with a stateless model where objects are activated/passivated for each use. I don't like using a database as RAM, but that's just me.
Some Hibernate patterns allow stateful programming models (such as the session-per-application-transaction pattern), and they are quite efficient.
But we believe that locking system and all the optimizations made by DB implementors in 20 years, cannot be reproduced that easily and that efficiently: we think its better to delegate such work to the DB engine. Locking at the data source. -
Second level cache ?[ Go to top ]
- Posted by: thoff thoff
- Posted on: November 06 2004 13:02 EST
- in response to Emmanuel Bernard
we think its better to delegate such work
>to the DB engine. Locking at the data source.
That is the royal we then?
Some problems with locking at the data source are:
1. not everything is data - lets say my transaction includes controlling a printer or a transient object that doesn't exist in the database. If you are using OO then a data approach makes you do some odd things to avoid using objects. Like lettings sessions rule your architecture.
2. data is not always the most efficient locking granularity. It's like java having a lock on every object. Better to have a lock at the highest level possible rather than at the lowest level.
3. eveything transits your database. If i am making a web server, for example, should all client sessions be in the database so i can persist them and handle locking? It would not perform well at all.
> Do you replicate this state yourself or do you
> know better ways to improve scalability ?
The object state still goes into the database and can be replicated in the database, but otherwise all locking and behaviours are in the objects. This all has a well known set of tradeoffs. Letting data dominate objects has too high a price imho. -
Second level cache ?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 06 2004 13:31 EST
- in response to thoff thoff
The object state still goes into the database and can be replicated in the database, but otherwise all locking and behaviours are in the objects. This all has a well known set of tradeoffs. Letting data dominate objects has too high a price imho.
It is not my problem, but EJB solves exactly this problem. I prefer let data to dominate objects, "objects and behaviours" sound good, but things like data consistency, performance and scalability are more important for me. -
Second level cache ?[ Go to top ]
- Posted by: Cameron Purdy
- Posted on: November 07 2004 18:25 EST
- in response to Juozas Baliuka
The object state still goes into the database and can be replicated in the database, but otherwise all locking and behaviours are in the objects. This all has a well known set of tradeoffs. Letting data dominate objects has too high a price imho.
It is not my problem, but EJB solves exactly this problem. I prefer let data to dominate objects, "objects and behaviours" sound good, but things like data consistency, performance and scalability are more important for me.
I don't understand how people can attribute such magical properties to Entity EJBs:
- Entity EJBs don't solve data consistency problems; instead they defer entirely to database transactions to do that work.
- Entity EJBs don't have any unique solutions for solving performance problems; most EJB containers support some form of local caching, at best.
- Entity EJBs don't solve scalability problems at all; again, they scale no better and no worse than the poor database that they dump all of the work onto.
While I wholeheartedly support the use of Entity EJBs for the cases in which they are a good fit, I think the worst thing that we can do to them is to try to imbue them with magical properties all over again.
Peace,
Cameron Purdy
Tangosol, Inc.
Coherence: Shared Memories for J2EE Clusters -
Second level cache ?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 08 2004 00:52 EST
- in response to Cameron Purdy
I am not EJB expert, but vendors say they are very good, so I trust it. -
Second level cache ?[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 06 2004 13:40 EST
- in response to thoff thoff
1. not everything is data - lets say my transaction includes controlling a printer or a transient object that doesn't exist in the database. If you are using OO then a data approach makes you do some odd things to avoid using objects. Like lettings sessions rule your architecture.
So, you use a more flexible transaction system that can handle several resources, e.g. CMT with EJBs.2. data is not always the most efficient locking granularity. It's like java having a lock on every object. Better to have a lock at the highest level possible rather than at the lowest level.
Interesting obvservation, but what you need for a lock are three things: a) what has to be locked b) by whom c) when. As you are hopefully aware of, you can define arbitrary locks (row level, table level, exclusive, shared, read, write, etc.) in modern database management systems. That should be flexible enough, even if it doesn't contain the word "object".3. eveything transits your database. If i am making a web server, for example, should all client sessions be in the database so i can persist them and handle locking? It would not perform well at all.
Thats why you have many options in todays J2EE systems to store and access your user sessions. I don't see the relationship of this and data management though. -
Second level cache ?[ Go to top ]
- Posted by: Dmitry Zemnitskiy
- Posted on: November 08 2004 10:01 EST
- in response to thoff thoff
I also recently met the same problem. I have requirements to cache data stored and retrieved to / from some database, but the problem is when transaction is rolled back, database doesn't store object while cache still has stored it as it doesn't participate in transaction. What I'm wondering, is hibernate + ehcache able to properly handle this situation?
I think no, as to solve it 2nd level cache should be transactional, like db does. Having 2nd laval cache transactional, for example implementing XAResource, will automatically solve all the ACID problems with objects, including isolation .
Does anybody have a look at activespace? Is it able to solve this problem?
Here's excerpt: ActiveSpace supports two core abstractions
* Spaces which provide a JavaSpace-like abstraction for building SEDA style grid based applications easily
* Caches which provide full support for transactional and clustered JCache support.
Does hibernate support ( or plans to add support ) of transactional 2-nd level caches ?
Thanks,
Dima -
Second level cache ?[ Go to top ]
- Posted by: Christian Bauer
- Posted on: November 08 2004 10:35 EST
- in response to Dmitry Zemnitskiy
Hibernate of course supports several fully transactional concurrency control strategies (providing different levels of isolation), depending on your performance needs for particular entity data and entity association data. The physical implementation of the cache (and possibly remote communication) is the job of the cache provider. -
Second level cache ?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 06 2004 12:48 EST
- in response to thoff thoff
> We make the database do the lockingThen you are fine with a stateless model where objects are activated/passivated for each use. I don't like using a database as RAM, but that's just me.
One of good ways to store this state on client, hidden form fields, URL parameters (I asume we are talking about web applications). It can sound as "evil" CGI way, but is very scalable. You can clone this kind of application without any session replication. One of ways is to use EJB, but as I understand it is not a good solution for your applications too. Do you replicate this state yourself or do you know better ways to improve scalability ? -
Second level cache ?[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 06 2004 02:42 EST
- in response to thoff thoff
ok - again, which session do you want the collection to load and save data through ?
Should it role a dice ? ;)
It is all for ensuring consistency in the data....if we did not do it I know we would get a lot of postings about "I have this multithreaded application that normally works, but suddenly the database gets inconsistent and even sometimes dead locks! What should i do ?" -
Second level cache ?[ Go to top ]
- Posted by: Juozas Baliuka
- Posted on: November 06 2004 03:23 EST
- in response to Max Andersen
I see some people prefer to blame for arogance to motivate ignorance. Probably the first entry in FAQ must sound like this "Please review instructions for software
requirements and detailed instructions on usage".
It doe's not sound arogant or rude, does it ? -
attitude[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 06 2004 02:38 EST
- in response to thoff thoff
Again, hibernate won't complain about different threads - it only complains if you put the same object in the same session. (please show me the error ?)
I guess what happens in your case is that you are actually first loading the user in session1 and then short after you take this user and associate him with session2 - and now that user is associated with two sessions and his possible collections will get confused, because which session should they now use to load data from ?
So, how would you control transaction isolation in the followiing scenario ?
Tx1: u1 = getUser(42);
Tx2: u2 = getUser(42);
u1 is now the same as u2 in your context
Tx1: u1.setName("Weird Al");
Tx2: u2.setName("Mamma Bird");
Who shall win this "race" ? Should the user be named "Weird Al" or "Mamma Bird" ? -
attitude[ Go to top ]
- Posted by: Max Andersen
- Posted on: November 05 2004 16:57 EST
- in response to thoff thoff
> I'm starting to get very offended by this > "right attitude" problem ;)When someone says your product stinks and has not future i wonder who should be offended?
Well, I saw a standard being mentioned as futureless, not a product! ...but enough of that - don't want to endulge into a offending game ;)My issue with hibernate is that you can't have an object in multiple simultaneous sessions in multiple threads. This really limits your threading model.
I have no idea what you are talking about here ;)
If you mean the same exact instance of an object, then I have a REAAALY hard time understanding why you would ever want to have multiple sessions running with the same object - that is breaking transaction isolation!
Regarding threads, then there is no limitations what so ever - so i don't follow what you are telling me ? -
JDO - the coolest underdog in town[ Go to top ]
- Posted by: geoff hendrey
- Posted on: November 05 2004 14:15 EST
- in response to Vitor Fernando Pamplona
Vendors who don't do JDO say JDO is dead. Far from it, all of the success JDO is enjoying has come from grass roots efforts, and JDO adoption is rapidly growing. And you just can't kill grassroots enthusiasm.
There are now 20+ commercial and OS JDO implementations. The Java community (i.e. developers) has always recognized choice as a good thing.
Vendors generally have a different agenda. They want to minimize choice by creating exclusive "clubs" around spec's and spec working groups. The more inertia around a spec, the harder for a competitor to enter the market.
After a rational look at what's out there, and the tasks at hand, many developers have chosen JDO and they are more than happy with their choice. We just have to get used to having choices.
So don't fret when bigshots tell you JDO is dead ... they wish!
-geoff -
The future of annotations[ Go to top ]
- Posted by: Yann Perrin
- Posted on: November 11 2004 16:33 EST
- in response to Vitor Fernando Pamplona
This might be a bit of innocent point of view.
I am not sure I support the use of annotations as widly as what seens to be the common opinion.
I can see how adding annotations to describe necessary behaviour for my component is a nice thing.
I am a bit more dubious about tagging my model classes with a description on how it is to be persisted. Is it not why we have a model, so that we have a layer representing the domain model without worrying about how those are persisted.
I understand that practically, it is unlikely that anybody will be changing the persistence model and that Hibernate already provides some isolation. But I am still not very confortable tagging my class as being persisted in a given table.
BTW I had problems making the jump between Relational database and object model. Hibernate made the jump much easier, thanks a lot! (Hibernate in Action helped a lot in the process).
Yann