667514 members! Sign up to stay informed.

Sponsored Links


Resources

Enterprise Java
Research Library

Get Java white papers, product information, case studies and webcasts

News News News Messages: 29 Messages: 29 Messages: 29 Printer friendly Printer friendly Printer friendly Post reply Post reply Post reply XML XML XML

Tech Talk with Gavin King on Hibernate

Posted by: Nitin Bharti on September 30, 2003 DIGG
Gavin King, founder of the Hibernate project, talks about how Hibernate got started, its success, and some of its best features. He discusses how Hibernate deals with stored procedures, the importance of transparent persistence, and the biggest challenges he faced building a persistence framework. He gives his opinion on JDO and bytecode manipulation, and describes how Hibernate uses CGLib.

Watch Gavin King's Interview


Update to Tech Talk UI
=======================

Due to popular demand, the full length text transcription of the interview has been integrated into the Tech Talk UI, which can be resized as needed.

Threaded replies

·  Tech Talk with Gavin King on Hibernate by Nitin Bharti on Tue Sep 30 12:06:41 EDT 2003
  ·  Tech Talk with Gavin King on Hibernate by Sandeep Dath on Tue Sep 30 13:20:03 EDT 2003
  ·  Interesting take on JDO by geoff hendrey on Tue Sep 30 14:39:37 EDT 2003
    ·  My Ugly Head. by Gavin King on Tue Sep 30 14:49:06 EDT 2003
      ·  My Ugly Head. by code freedom on Tue Sep 30 15:19:20 EDT 2003
      ·  re: My Ugly Head. by Craig Doremus on Tue Sep 30 19:16:35 EDT 2003
        ·  Caching by Aaron Robinson on Wed Oct 01 02:45:59 EDT 2003
          ·  Caching by Juozas Baliuka on Wed Oct 01 03:22:58 EDT 2003
          ·  caching etc by Gavin King on Wed Oct 01 05:24:16 EDT 2003
            ·  More caching questions by Aaron Robinson on Wed Oct 01 09:37:51 EDT 2003
              ·  More caching questions by Gavin King on Wed Oct 01 11:24:16 EDT 2003
                ·  my bad by Gavin King on Wed Oct 01 11:30:25 EDT 2003
                  ·  cache forwarding by Sean McDaniel on Wed Oct 01 12:43:56 EDT 2003
      ·  optimization of sql queries by Gina Hagg on Wed Oct 01 16:11:44 EDT 2003
        ·  optimization of sql queries by Sandeep Dath on Wed Oct 01 16:27:11 EDT 2003
          ·  right you are. by Gina Hagg on Wed Oct 01 16:39:53 EDT 2003
            ·  Hmm by Sandeep Dath on Wed Oct 01 17:02:55 EDT 2003
              ·  ibatis by Gina Hagg on Wed Oct 01 18:30:15 EDT 2003
                ·  ibatis by Sandeep Dath on Wed Oct 01 19:57:55 EDT 2003
          ·  optimization of sql queries by shy shadow on Fri Jun 17 05:13:09 EDT 2005
        ·  optimization of sql queries by Sandeep Dath on Wed Oct 01 16:42:27 EDT 2003
          ·  hey by Gina Hagg on Wed Oct 01 16:49:46 EDT 2003
        ·  direct SQL by Gavin King on Thu Oct 02 11:50:58 EDT 2003
          ·  yeppiee by Gina Hagg on Thu Oct 02 17:12:15 EDT 2003
      ·  ****JDO2 addresses every concern I hear mentioned any more****** by Matthew Adams on Thu Oct 02 21:39:35 EDT 2003
        ·  JDO 2.0 process by Marc Logemann on Fri Oct 03 16:00:38 EDT 2003
  ·  Tech Talk with Gavin King on Hibernate by Flavio Donaire on Tue Sep 30 17:51:04 EDT 2003
    ·  Tech Talk with Gavin King on Hibernate - correction by Rodolfo de Paula on Tue Sep 30 18:00:36 EDT 2003
  ·  Great interview by Stu Charlton on Sun Oct 05 10:02:06 EDT 2003
  ·  Rod Johnson's AOP hierarchy? by Steven Shaw on Wed Oct 08 02:08:10 EDT 2003
  Message #97294 Post reply Post reply Post reply Go to top Go to top Go to top

Tech Talk with Gavin King on Hibernate

Posted by: Sandeep Dath on September 30, 2003 in response to Message #97280
You go Gavin!

Sandeep.

  Message #97313 Post reply Post reply Post reply Go to top Go to top Go to top

Interesting take on JDO

Posted by: geoff hendrey on September 30, 2003 in response to Message #97280
Gavin is very articulate and should definitely participate in the JDO 2.0 spec.

He was, however, wrong when he said that JDO requires bytecode enhancement. JDO requires the PersistenceCapable interface to be implemented, and the enhancer is an automatic way to do it. But sourcecode enhancers, or plain old hand coding of the PersistenceCapable interface are perfectly OK as well.

I think one thing that will close the gap between JDO and Hibernate (or unify them) is the capability to use straight SQL instead of JDOQL to specify queries. JDO allows alternate languages to be used besides JDOQL for query formulation, and SQL would be the most obvious alternative. There would be no issue with outer joins, ordering, etc. if SQL could be used to issue the query.

Hoperfully Gavin can help bring JDO forward.

-geoff

  Message #97316 Post reply Post reply Post reply Go to top Go to top Go to top

My Ugly Head.

Posted by: Gavin King on September 30, 2003 in response to Message #97313
A quick note: this was recorded at the TSS symposium, before the JDO 2 process started, and before I became involved.

>>He was, however, wrong when he said that JDO requires bytecode enhancement.<<

I misspoke slightly. I tried to say that "JDO requires byte-code processing if /transparent/ persistence is required". Emphasis upon "transparent". (

OK, I admit that you can also do it with sourcecode processing, but the same criticisms apply to sourcecode processing!)

Anyway, this debate is becoming quite irrelevant, since changes are being made in the scope of JDO 2.0 (along the lines I describe in the interview).

  Message #97318 Post reply Post reply Post reply Go to top Go to top Go to top

My Ugly Head.

Posted by: code freedom on September 30, 2003 in response to Message #97316
"this was recorded at the TSS symposium"

ah, that explains why no questions about Hibernate-JBoss ;-)

  Message #97324 Post reply Post reply Post reply Go to top Go to top Go to top

Tech Talk with Gavin King on Hibernate

Posted by: Flavio Donaire on September 30, 2003 in response to Message #97280
TSS : "Why do you think Hibernate has become so successful? "

Gavin : "...Secondly: Documentation. So many of the great Java open source projects that are out there could be so much more successful, and so much better as a project if people took the time to take pride in the documentation..."

I wish folks at JBoss Group could learn from this advise. I am not refering to WEB or EJB containers but the new hot stuff (AOP, distributed/transacional cache/singletons, etc). Ok, we can read JavaDocs, but if JBoss Group is really trying to be Professional Open Source, why not produce some professional documents ? And what about Executive Summary kind of documents ? How I "sell" JBoss to my manager or to my clients ? (Please dont say me I need to get certified...).

Ok, I can talk about the new business model around Open Source, etc but in general many people still did not got it !

If I wish to convince some potential customer about JBoss, I cannot start talking things like "The truth is in the Code". Get real, get professional !

Congratulations Gavin !

  Message #97326 Post reply Post reply Post reply Go to top Go to top Go to top

Tech Talk with Gavin King on Hibernate - correction

Posted by: Rodolfo de Paula on September 30, 2003 in response to Message #97324
Just to correct my name. I used my colleague workstation and he was previously logged in TSS so...

:)

  Message #97328 Post reply Post reply Post reply Go to top Go to top Go to top

re: My Ugly Head.

Posted by: Craig Doremus on September 30, 2003 in response to Message #97316
Gavin:
Now that you are involved in the JDO expert group, what are your current thoughts on if or when Hibernate will become JDO compliant?

  Message #97346 Post reply Post reply Post reply Go to top Go to top Go to top

Caching

Posted by: Aaron Robinson on October 01, 2003 in response to Message #97328
One of the nice (but not nearly nice enough) things to come out of a CMP2 (WLS 8.1) vs. JDBC comparison was the caching that the CMP2 takes off your hands.

Does Hibernate support caching of the query results and if so to what extent?

If it doesn't have it's own cache, what are people using on top of Hibernate?

As for SQL in code not being ugly, well, maybe not, provided that the SQL is well encapsulated. One of the downsides of the exposed SQL approach is that developers use it! and use it, and use it, all over the place. So if your underlying schema changes you end up having to make multiple changes (after you've found them).

How would this be achieved in a world where the SQL is distributed throughout the code?

The reality of the matter is that if you present developers with SQL via Hibernate, they will use it like SQL and you suffer from the same issues.

I haven't actually looked at Hibernate in any detail, and am relying on the interview alone so please excuse any ignorance on my part. If these issues I've raised are not issues then I'd love to know.

  Message #97349 Post reply Post reply Post reply Go to top Go to top Go to top

Caching

Posted by: Juozas Baliuka on October 01, 2003 in response to Message #97346
Looks like caching is priority in hibernate 2, it is not trivial to implement distributed cache for all use cases with transction isolation support, cache can be the overhead itself in some of use cases.
But I found it is very trivial to implement it for specific use cases like web applications. Content cache in web applications saves more operations than cache in low level operations, filter "knows" specific needs and can optimize application very well. "Send-If-Modified" is a very good optimization for web application too (Cache on client). Tools like OSCache can help to optimize "Model 1" web app better than persistence layer too.
I like this dream "no cache in client code and 100% of performance at low level", but I do not believe it.

> One of the nice (but not nearly nice enough) things to come out of a CMP2 (WLS 8.1) vs. JDBC comparison was the caching that the CMP2 takes off your hands.
>
> Does Hibernate support caching of the query results and if so to what extent?
>
> If it doesn't have it's own cache, what are people using on top of Hibernate?
>
> As for SQL in code not being ugly, well, maybe not, provided that the SQL is well encapsulated. One of the downsides of the exposed SQL approach is that developers use it! and use it, and use it, all over the place. So if your underlying schema changes you end up having to make multiple changes (after you've found them).
>
> How would this be achieved in a world where the SQL is distributed throughout the code?
>
> The reality of the matter is that if you present developers with SQL via Hibernate, they will use it like SQL and you suffer from the same issues.
>
> I haven't actually looked at Hibernate in any detail, and am relying on the interview alone so please excuse any ignorance on my part. If these issues I've raised are not issues then I'd love to know.

  Message #97359 Post reply Post reply Post reply Go to top Go to top Go to top

caching etc

Posted by: Gavin King on October 01, 2003 in response to Message #97346
>> Does Hibernate support caching of the query results and if so to what extent? <<

* allows lookups-by-id may be cached with configurable semantics on a per-class level
* query result sets may be cached in Hibernate 2.1, by calling Query.setCacheable(true)

So, basically: to the full extent ;-)

Currently, distributed caching is possible using tangosol coherence, and - through the JBoss connection - I am working with Bela Ban of JavaGroups to get an out-of-the-box distributed cache implementation.

>> As for SQL in code not being ugly, well, maybe not, provided that the SQL is well encapsulated. One of the downsides of the exposed SQL approach is that developers use it! and use it, and use it, all over the place. <<

Actually, this was not quite my point. We don't encourage people to sprinkle SQL all through their code - we just encourage them to make full use Hibernate's query language and query API when working with large sets of data. The query language is an object-oriented query language similar to ODMG OQL.

>>So if your underlying schema changes you end up having to make multiple changes (after you've found them).<<

Hibernate queries are always expressed in terms of classes and properties, not in terms of tables and columns, so this is just not a problem. The mapping document centralizes knowledge of the underlying relational schema.

  Message #97381 Post reply Post reply Post reply Go to top Go to top Go to top

More caching questions

Posted by: Aaron Robinson on October 01, 2003 in response to Message #97359
Thanks for the info Gavin,

It sound like the caching in 2.0 is exactly the same as the WLS 8.1 CMP2 caching (by primary index).

One of the drawbacks of the WLS approach is that for a designated read only bean, a finder on anything other than the pk will involve a database hit. If it is read only then any finder should be cached but preferably only through a secondary cache that is keyed by name with the PK as the value which the container/Hibernate can use to query the main cache.

You say that you have a query results cache and at first sight it seems that this would resolve the above use case, but does this mean it will literally cache the entire results of the query or is it clever enough to refer to the main cache by primary index? If not then I can see the heap getting used up quickly.

How will Hibernate deal with cached data becoming invalidated as the result of a database change. For example, how would the read-mostly pattern be implemented in Hibernate effectively?

  Message #97395 Post reply Post reply Post reply Go to top Go to top Go to top

More caching questions

Posted by: Gavin King on October 01, 2003 in response to Message #97381
>>>You say that you have a query results cache and at first sight it seems that this would resolve the above use case, but does this mean it will literally cache the entire results of the query or is it clever enough to refer to the main cache by primary index?<<<

It is clever.


>>How will Hibernate deal with cached data becoming invalidated as the result of a database change. <<

It invalidates cached results from queries that referred to the updated table. (And yes, this will also work in a cluster.)


The only thing to mention is that the query cache is necessarily less fussy about transaction isolation than the object cache. But this is perfectly fine, actually.

  Message #97397 Post reply Post reply Post reply Go to top Go to top Go to top

my bad

Posted by: Gavin King on October 01, 2003 in response to Message #97395
>>How will Hibernate deal with cached data becoming invalidated as the result of a database change. <<


Ooops I think I misunderstood. You mean a change made from outside Hibernate? Well, my answer is basically the same as the Toplink guys and anyone else I've ever seen talk about this: you would have to manually implement some kind of callback from the database into the J2EE server (using a trigger + JMS, or whatever) and then call the API we provide for cache invalidation.

Or, if the update is performed from inside the same application, but just not through Hibernate, just call the API directly. (There is an evict() method.)

This is becoming a common question, actually.....

  Message #97410 Post reply Post reply Post reply Go to top Go to top Go to top

cache forwarding

Posted by: Sean McDaniel on October 01, 2003 in response to Message #97397
it seems that it would be more efficient to forward
the change set instead of an eviction notification.
the question of how to notify other processes that
an update has occurred outside of the applications
persistence layer is common and there are techniques,
as gavin notes, to solve this.

one of the problems with the cache synchronization
solutions that i've seen is that they all based on
a peer type architecture. it's not really a problem,
what i mean is they take an application perspective
on the caching problem and developers must handle
scenarios when data is modified outside of the
applications persistence layer.

i think a cache forwarding architecture would be
interesting to see in the OR space and would take
the burden of managing the possibility of having
stale data/instances in the cache. so instead
of peers sending messages between one another,
change set notifications come from the back end
forward. i know that this is a difficult and
perhaps silly idea, but i saw how this worked
in object store and it left an impression on me.
damn i miss working with oodbms.
 
sean

  Message #97434 Post reply Post reply Post reply Go to top Go to top Go to top

optimization of sql queries

Posted by: Gina Hagg on October 01, 2003 in response to Message #97316
Gavin,
hibernate is certainly a great idea.
However, i don't see why i really would need to use HQL which is another learning curve for me. Why is it so hard for developers to learn sql. Why is that so uncool? i really don't like HQL, and i prefer to be able to use my own sql statements.

okay, since i like hibernate, let's say that i could live with HQL, but, how about when i really need to tune the sql statements. I might want to do table ordering (small table first maybe) i.e in joins , use hints and whether i want nested loops etc.. How do i do that. I understand that one can actually see the sql statement that is being created dynamically by Hibernate, and i suppose , i could optimize that, but then, what is the purpose of you creating the sql statement at the first place.

I suppose , I am having a hard time with hibernate creating complicated join queries for me when these are the ones that can bring down a database. I know my database and know how the query needs to be written because, i have created the necessary indexes, i know my tables etc.. I have a hard time trusting that a dynamically random written query will ever reach the speed and optimization i can.

I just would like to understand this part. I think, it is one of the points that i am resisting about most. this and the issue of stored procs. I really like stored procs and what i can do with them. It is a pity that hibernate doesn't accomodate them yet since there is no callable statement, from what i read.

I like hibernate when the queries are simple. It takes care of lotsa complexities for me.. So, please enlighten me about the above issues. I would really appreciate it.

  Message #97440 Post reply Post reply Post reply Go to top Go to top Go to top

optimization of sql queries

Posted by: Sandeep Dath on October 01, 2003 in response to Message #97434
Um, did you hear the part in the interview about fulfiling the need to be able to work with "sets of objects" vs. merely "sets of data".

If you want to do the former, well its easier doing that with Hibernate, or any equivalent ORM tool, than with raw SQL and JDBC. Of course there are tools such as iBATIS that can help you in this realm as well.

That said, if you want to really bridge the O & R worlds, while being able to leverage the strength of portable, POJO-based object-oriented progamming constructs, while maintaining the flexibility to do ad-hoc, querying a la SQL - well you really have no recourse but to use a utility like Hibernate.

Also, did you also read the part about being able to use the native JDBC connection to execute your own SQL queries in the same transaction context as your HSQL queries/Hibernate persistence operations?

Sandeep.

  Message #97441 Post reply Post reply Post reply Go to top Go to top Go to top

right you are.

Posted by: Gina Hagg on October 01, 2003 in response to Message #97440
since %90 of my interaction with my own database is batch inserts/deletes, stored procs, and very complicated reporting joins, and joins, which i can do through exposed jdbc, which i must do by not hiding behind hibernate, then, what does this leave me with.. And i have to learn hql besides.

  Message #97442 Post reply Post reply Post reply Go to top Go to top Go to top

optimization of sql queries

Posted by: Sandeep Dath on October 01, 2003 in response to Message #97434
The other thing is that nobody really said anything about SQL being uncool. For example, going back to Gavin's interview, he said:

<Gavin>
"I’m kind of ashamed to say that in the Java community, I think often, we look at that stuff and think it’s a bit dirty and people talk about persistence layers as being able to shield the developer from having to work with that kind of stuff. But if you actually sit down and spend some time thinking about the relational model and relational modeling, you realize it’s actually very elegant. What makes it dirty is the mismatch problem, is the mapping problem, that’s the only part that makes it dirty. What makes it dirty is working with JDBC and trying to map the stuff that comes out of JDBC onto a graph of objects. That’s what makes it dirty, not writing SQL, not working with SQL.
</Gavin>

If you understand SQL well, and from your post, I am guessing you are very well versed with SQL, there really is no "learning curve" to HQL. Its closer to SQL that most other object-oriented query languages.

Sandeep.

  Message #97443 Post reply Post reply Post reply Go to top Go to top Go to top

hey

Posted by: Gina Hagg on October 01, 2003 in response to Message #97442
never said anything about Gavin saying that. Read my post. i was just complaining about the same thing exactly..
Plus, there was a talk in the mailing list about making stored procs available through making callable available in hibernate which got me all excited. because that would solve lotsa problems for me. Don't get me wrong, i really like hibernate.. so, you don't have to defend it to me.

  Message #97445 Post reply Post reply Post reply Go to top Go to top Go to top

Hmm

Posted by: Sandeep Dath on October 01, 2003 in response to Message #97441
<gina>
since %90 of my interaction with my own database is batch inserts/deletes, stored procs, and very complicated reporting joins, and joins, which i can do through exposed jdbc, which i must do by not hiding behind hibernate, then, what does this leave me with
</gina>

Sounds like you may have an application need that is not amenable to using Hiberate as advertised in Examples 1-10. ;-)

There has been a lot of discussion on best practices with respect to batching DML using Hibernate. Here is a verbatim extract from the mailing list.

<hibernate-devel>
On 01 Sep (18:00), Butt, Dudley wrote:

> Has anyone got any pointers on how to perform a batch insert into? like 3000 +
> records

With SQL and JDBC calls.

--
Christian Bauer
</hibernate-devel>

The same thing applies to stored procs and complex joins aimed at reporting.

Also, maybe Hibernate isn't what you're looking for. After all, one size never fits everybody.

If you want to abstract away complex persistence issues while focussing on your business logic, then Hibernate can really help you. If you persist with the perspective of dealing with persistence issues first (terribleainti!), then well, you are probably better off with SQL and JDBC.

The one thing that you have to remember is that when using an ORM tool, you have to leave some of the procedural/SQL (not a reference to PL/SQL) mentality and paradigms behind. Gavin said it well when he talked about "working with sets of objects".

With objects, it's mostly about the relationships between them. It's not about sets of data that can be joined together. This problem is accentuated because data models look deceptively similar to their corresponding object models.

It's also important to remember that object models aren't just data models with some behavioral semantics thrown in for good measure.

To quote Scott Ambler (loosely) - while the OO paradigm is based on proven software engineering principles, the relational paradigm is based on proven mathematical principles.

Sandeep

  Message #97454 Post reply Post reply Post reply Go to top Go to top Go to top

ibatis

Posted by: Gina Hagg on October 01, 2003 in response to Message #97445
i did look at the iBatis (and i remembered that Gavin talks about it in the first chapter of the new Hibernate book.)
yes, indeed, it looks like exactly what i would need. Thanks for bringing to my attention Sandeep. ;)

  Message #97461 Post reply Post reply Post reply Go to top Go to top Go to top

ibatis

Posted by: Sandeep Dath on October 01, 2003 in response to Message #97454
> i did look at the iBatis (and i remembered that Gavin talks about it in the first chapter of the new Hibernate book.)
> yes, indeed, it looks like exactly what i would need. Thanks for bringing to my attention Sandeep. ;)

Your welcome. ;-)

I've used it myself. Its really best in its class.

Sandeep.

  Message #97510 Post reply Post reply Post reply Go to top Go to top Go to top

direct SQL

Posted by: Gavin King on October 02, 2003 in response to Message #97434
>>Why is it so hard for developers to learn sql. Why is that so uncool? i really don't like HQL, and i prefer to be able to use my own sql statements.<<

Max Anderson has added support for native SQL queries to Hibernate 2.1. It actually works out very nicely. You don't need to do all the yucky JDBC stuff - let Hibernate take care of that - and you can still do all the "hard" stuff like query hints, etc.

OTOH, direct SQL queries are MUCH more verbose and much less readable than HQL. HQL and the new Criteria API - which is actually really cool - work at a slightly higher level of abstraction.

  Message #97541 Post reply Post reply Post reply Go to top Go to top Go to top

yeppiee

Posted by: Gina Hagg on October 02, 2003 in response to Message #97510
well, let's present heart felt thanks and gratitude to mr.Max Anderson then.. Thank you.. thank you.. thank you..

about sql being more noisy. don't know.. it is like someone telling you that your native language is hard to learn, you don't understand why he/she says that, cause, you learned it as a child, bad example, but i am just so used to dealing with sql and how i can play around with it , it makes it rather fun and don't even think of it as being difficult.
Thanks Gavin..

  Message #97545 Post reply Post reply Post reply Go to top Go to top Go to top

****JDO2 addresses every concern I hear mentioned any more******

Posted by: Matthew Adams on October 02, 2003 in response to Message #97316
I can say without exception that every complaint that I've heard about JDO1 is being addressed in JDO2. Hibernate and Toplink are fully on board, as far as I can tell (I'm on the expert group, too), with JDO2.

* One of the explicitly stated goals of JDO2 is to broaden the number of implementations of transparent persistence, essentially making optional binary compatibility and the javax.jdo.spi.PersistenceCapable interface.

* Since most, if not all, of the current JDO1 ORM implementations already expose the JDBC connection in a proprietary way, this will be standardized.

* JDOQL will be enhanced to include support for aggregation and projections, including things like count, sum, avg, min, max, etc.

* Recommendations will be made regarding SQL such that, if the user abides by them, all implementations are expected to be able to handle and map results into the appropriate objects. Personally, I throw this under the label "JDOSQL", but "SQL" might be just as appropriate here, because it's the very language for which support is intended. What the spec will use, I don't know, but I expect it to be enumerated along with JDOQL.

* More concrete collections from the Java collections framework will be supported.

* The ability to use simple object identities, much like how Hibernate's use of object identities, will be added.

* The expression of object-to-relational mappings is also being standardized as well, so that you can change JDO implementations without having to go through a data migration, provided that your mappings abide by the portability requirements.

There are also a number of additional things going into the spec, but these are certainly the highlights.

I hope this helps ease some of the worries that people have about JDO.

--matthew

  Message #97594 Post reply Post reply Post reply Go to top Go to top Go to top

JDO 2.0 process

Posted by: Marc Logemann on October 03, 2003 in response to Message #97545
> * One of the explicitly stated goals of JDO2 is to broaden the number of
> implementations of transparent persistence, essentially making optional
> binary compatibility and the javax.jdo.spi.PersistenceCapable interface.

I really dont care about binary compatibility regarding my enhanced Pojos, on this point, i agree with Gavin. Making the interface PersistenceCapable optional would mean that the implementor has full control over how things are done behind the scenes or are there other issues there?

BTW how about dropping support for PersistenceAware classes. Direct access on attributes is bad style anyway, PAware classes will only enforce this behavior.

> * JDOQL will be enhanced to include support for aggregation and projections, including things like count, sum, avg, min, max, etc.

hardly to believe that this wasnt speced out in 1.0. Major shortcoming.

> * The ability to use simple object identities, much like how Hibernate's use of object identities, will be added.

dont know what you mean with this, because i dont know hibernates way of doing this ;-) But sounds interessting.

> * The expression of object-to-relational mappings is also being standardized as well, so that you can change JDO implementations without having to go through a data migration, provided that your mappings abide by the portability requirements.

This is also a MUST-DO.

> I hope this helps ease some of the worries that people have about JDO.

If you let aside the JDOQL issue, JDO is a very nice ORM spec from the user perspective. 1.0 has shortcomings, yes, but the overall direction is nice and 2.0 will hopefully the long awaited breakthrough.

Marc

  Message #97676 Post reply Post reply Post reply Go to top Go to top Go to top

Great interview

Posted by: Stu Charlton on October 05, 2003 in response to Message #97280
" I’m not an expert on object databases but I suspect in the case of object databases they’re a bit more designed to cope with that method of data access. "

Yeah, they tend to include collections that chunk up the persistent collecitons into buckets so they can be pulled into memory in batches as opposed to N+1.

" And that’s not going to work because a relational database is fundamentally different. The way you access data in the relational database is fundamentally different from the way you access data in an object database"

Key point. A lot of people actually wind up writing 1/3 of a relational query & index engine on top of their ODBMS when working with it (I know I did).

"What makes it dirty is working with JDBC and trying to map the stuff that comes out of JDBC onto a graph of objects. That’s what makes it dirty, not writing SQL, not working with SQL. "

This is is a key point and I wish more developers saw things this way. It would eliminate a lot of project and performance failures out there because people tried to hide something that is way too rich to be hidden.

"Stored procedures are essentially a non-relational view of a relational database. They're a procedure oriented, a call oriented view of a relational database. So my view, and this is a controversy, not everybody agrees with it"

I understand this view, and I used to agree with it, but there are problems with it. I had a disagreement with Gavin over this very idea a few weeks back.

Certain kinds of security checks and semantic integrity constraints need to be written as SQL statements (they are too complex to be declarative CHECK constraints or simple foreign key constraints). This is a form of "data level" business logic.

Anyway, such checks can either "front-end" your main SQL statement, or they can be implemented with triggers. The problem is that cascading triggers can really lead to hard-to-control side effects, not to mention some difficult to measure performance characteristics (when they get more complicated). Finally, with Oracle, their locking paradigm causes the mutating table problem when dealing with sets of data.

All of this is why you see a lot of DBAs that insist on turning off dynamic SQL and insisting on stored procedures + views for data access. They are a way of ensuring complex integrity and security constraints BUT they still keep the possibility of "shared data" among applications. They prevent any non-approved means of accessing the data. This is widely used in production.

The other defense for stored procedures is a pure performance argument: a stored procedure is in-process with the database. It is going to be an order of magnitude faster than pulling data across a network into an application server and hibernate. Plus, modern databases have features like "bulk binding" and "procedure pipelining" which can enable tremendous (order of magnitude) performance gains when dealing with large sets of data.

Having said all of this, Gavin is, at the core, correct: stored procedures are a call oriented interface. But this is exactly what most distributed systems interfaces are - they're coarse-grained and call-oriented, just like a stateless session bean or a web service. Fine-grained stateful domain models don't make sense when you're building a network interface - something we learned the hard way with CORBA. What needs to happen, perhaps, is a greater emphasis on improving Java's performance in the database, as an alternative to PL/SQL or T-SQL: would you rather write code in them or in Java (assuming performance was the same)? This is the direction Microsoft is going with SQL Server Yukon by embedding C# inside the database with the same performance characteristics of T-SQL: it will give Oracle and Sybase more incentive to improve their "Java in the database" implementations.

"Firstly, to address the first part: that some vendor’s customers aren’t asking for that. Well, my view on that is that who are they defining as their customers? Are they defining their customers as the developers who work with their products day to day? ... To me, it appears, the interest in Hibernate should demonstrate, that in fact, that developers are very, very, interested in the problem of transparent persistence. "

I said this before, and I'm not sure Gavin will believe me, but I'll re-iterate it: developers in most enterprise shops in the telecom and financial industry that I've dealt with (and I've dealt with quite a few) write their systems with JDBC and stored procedures, and think writing a stored procedure is a lot easier than setting up an ORM tool.

I've tried to sell them on the merits of ORM, it has been a very slow process. In the ensuing years, I've tended to come around and see the merits of the stored procedure approach, but I still think ORMs are very useful, just as long as the team using it is careful about understanding its tradeoffs.

Most Java people "in the trenches" that have a C++ heritage aren't hanging out on theserverside.com, they're not really aware of the Java community out there. It's a bit of a paradigm shift. This is slowly changing: a recent client has their main global trading system built on top of Persistence Powertier, primarily for its caching abilities. It's unfortunate that Powertier hasn't really been updated much in recent years (they're focusing on EdgeXtend) as it gives developers a taste for the clunky EJB-1.1 style of ORM.... whereas lightweight ORM technology has really matured recently.

The trend I notice is that shops tend to look towards the more modern frameworks when they start to hire "fresh perspective" CS graduates and java developers that are popping up out there, those that haven't been coding for 10+ years with a C++ heritage (or perhaps those from a Smalltalk heritage). They manage to convince management of the brave new world of the Java approach - ORMs, EJBs, Struts, AOP, etc... and things progress from there. Unfortunately, these "blue sky" developers don't have the 10+ years of C++ behind them to see the merits of the old approach and the trade-offs of the new approach. This can (quite often in my experience) lead to a lot of headaches and non-performing systems. I was guilty of this once, in the mid to late 1990s, but I was lucky in not presiding over too many disasters (but pretty close)... I've been trying to avoid that over the past few years.

"Firstly, not every application needs a domain model. There are lots of applications for which a domain model is absolute overkill. There are lots of applications for which a view of sets of data coming out of the database is absolutely appropriate. "

Very true, and I wish more of the Java purists understood this.

Anyway, great interview.

  Message #97939 Post reply Post reply Post reply Go to top Go to top Go to top

Rod Johnson's AOP hierarchy?

Posted by: Steven Shaw on October 08, 2003 in response to Message #97280
> Rod Johnson didwas he wrote up a hierarchy of the ways to implement
> it where he started off with dynamic proxies and ended up with a new
> language like AspectJ

Where can I find this?

  Message #174932 Post reply Post reply Post reply Go to top Go to top Go to top

optimization of sql queries

Posted by: shy shadow on June 17, 2005 in response to Message #97440
<Gina>
okay, since i like hibernate, let's say that i could live with HQL, but, how about when i really need to tune the sql statements. I might want to do table ordering (small table first maybe) i.e in joins , use hints and whether i want nested loops etc.. How do i do that. I understand that one can actually see the sql statement that is being created dynamically by Hibernate, and i suppose , i could optimize that, but then, what is the purpose of you creating the sql statement at the first place.

I suppose , I am having a hard time with hibernate creating complicated join queries for me when these are the ones that can bring down a database. I know my database and know how the query needs to be written because, i have created the necessary indexes, i know my tables etc.. I have a hard time trusting that a dynamically random written query will ever reach the speed and optimization i can.
</Gina>

That's exactly what I need. I have a performance issue with my database and the solution I found, is to optimize the sql query.
How could I add hints in my HQL query ?

New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com

Dependency Injection in Java EE 6 - Part 1

Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6. (November 2, Article)

SAML: It's Not just for Web services

SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options. (September 28, Article)

Programming is Also Teaching Your Team

Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team. (September 22, Article)

Can Java EE Deliver The Asynchronous Web?

Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies. (July 14, Article)

JSF Flex

JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags. (June 29, Article)

The Rules of SOA - A Road to a Successful SOA Implementation

In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project. (June 23, Tech Talk)

Ari Zilka Talks About Terracotta 3.1

Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now. (June 15, Tech Talk)

Enterprise Application Integration, and Spring

In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements. (June 15, Tech Talk)

Google Web Toolkit: An Introduction

In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls. (June 4, Tech Talk)

Just Enough Early Architecture to Guide Development

Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable. (May 28, Tech Talk)

Productive Programmer: On the Lam from the Furniture Police

This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work. (May 26, Tech Talk)

Auto-Scaling Your Existing Web Application

Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers. (May 21, Tech Talk)

Automating Hibernate Mapping and Queries For Java Web Development

Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application. (May 19, Article)

Auto-Scaling Your Existing Web Application

In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources. (May 19, Tech Talk)

Free Book: Jakarta-Struts Live

Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)

Application Server Matrix

The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)

News | Blogs | Discussions | Tech talks | Patterns | Reviews | White Papers | Downloads | Articles | Media kit | About
Java Solutions
All Content Copyright ©2007 TheServerSide Privacy Policy
Site Map