"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

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 ;)

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.

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)?

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.

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!

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?

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.

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

"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 :)

Any plans for docs/book to get hibernate2 users up to speed with hiberate3 ?

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).

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)

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.

Could you name one of the features that Hibernate is missing?

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.

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 ;)

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.

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.

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.

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 ?

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).

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).

I am very glad if it helps.

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 !!

How is Hibernate handling locking on MSSQL DB (its lock hints)?

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

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.

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

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.

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.

As mentioned by Gavin in the interview, Hibernate3 is a superset of EJB3.

Oops, of EJB3 _persistence_.

"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")

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

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

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 ;)

We have excellent support for large collections in Hibernate, but we call them "Bags".

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.

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!

This is a surprising thing to say, considering that the JDO marking is thriving.

Sorry - marking = market

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?

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.

"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?

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.

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.

"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

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

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?

When did EJB became high performant?

Since the local call feature of EJB2

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.

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.

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.

shameless plug - but Hibernate has the same advantage, and the upcoming unioned persistence api will also have these advantages :)

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.

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.

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.

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.

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 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.

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....

Dave, as to you 4 questions, many found answer in iBatis.
It's very scalable BECUASE it is E/R and SQL based.
.V

Looks interesting, but doesn't appear to be able to do stored procedures.

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.

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" ?

By "connected" I mean directly using a JDBC connection to access the data, and then "manually" populating the data objects and cache.

Dave.

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 better

4. 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 ;)

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.

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

EJB is designed for this use case. Why do you want to replace EJB with hibernate ?

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...&nbsp;- Don

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 ;-)


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.

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.

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 ? :)

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.

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

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.

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.

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 ?

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.

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.

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

I am not EJB expert, but vendors say they are very good, so I trust it.

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.

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

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.

> 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 ?

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 ?"

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 ?

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" ?

> 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 ?

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

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