• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The price of JDO

 
Dirk Schreckmann
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roger Goerke:
This JDO seems a little too good to be true. There must be some price to pay for all the flexibility listed in the requirements.
Is JDO a performance killer? How does JDO get access to the private persistable attributes and how does JDO know that an object is dirty?
Any background info provided will be helpful for me to understand why I might consider using them over EJB.
 
Craig Russell
Author
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JDO does seem too good to be true, but it's real. The experts who designed JDO looked at previous efforts and deliberately made design decisions that made performance easy.
For example, JDOQL is easy to use because it looks a whole lot like Java, but it's high performance because a JDOQL query can be 100% translated into a SQL query. Unlike OQL, you don't have to execute part of the query in the back end and part in the front end.
Another example: JDO specifies an object cache that can be used with or without transactions, and can even be used with a combination. For example, you create a new user in a transaction and then display information about the user. The creation of the user instance is transactional; accessing related information after the transaction is complete can be done without the overhead of a transaction.
If you read the literature on database performance, you will quickly find that "it's all about caching". And JDO standardizes caching semantics so you can take advantage of caching with numeroud implementations.
Originally posted by Dirk Schreckmann:
This JDO seems a little too good to be true. There must be some price to pay for all the flexibility listed in the requirements.
Is JDO a performance killer? How does JDO get access to the private persistable attributes and how does JDO know that an object is dirty?
Any background info provided will be helpful for me to understand why I might consider using them over EJB.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 35279
384
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about the actual optimization? Some queries can't be cached (no repetition) or the performance of the initial query is horrible.
Does JDO let you optimize to use indexes? Does JDO deal on an object/row level or a field/column level?
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeanne Boyarsky:
What about the actual optimization? Some queries can't be cached (no repetition) or the performance of the initial query is horrible.
Does JDO let you optimize to use indexes? Does JDO deal on an object/row level or a field/column level?

The JDO implementation gives you some way of mapping the Java object model into the database schema, right? Isn't this then purely a question of optimizing that schema within the database with the database vendor's tools?
As to the question about object/row vs field/column level, I believe JDO lets you deal with objects and nothing more -- the whole point is to not think about tables, rows and columns but simply objects of which state needs to be persisted.
Do I make sense?
 
Craig Russell
Author
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your responses make perfect sense. The JDO implementations are responsible for mapping the domain model represented by JDO classes into the database schema.
The mapping can be forward (classes generate schema); backward (schema generate classes); or bridge (existing classes, existing schema, you map them yourself).
The choice of mapping is often at issue with inheritance and relationships, and JDO vendors give you flexibility in the mapping. You might optimize for performance by having all subclasses in one table; or optimize for third normal form by having subclass information in separate tables.
We discuss this issue in the book, with an entire chapter devoted to mapping issues.
Originally posted by Lasse Koskela:

The JDO implementation gives you some way of mapping the Java object model into the database schema, right? Isn't this then purely a question of optimizing that schema within the database with the database vendor's tools?
As to the question about object/row vs field/column level, I believe JDO lets you deal with objects and nothing more -- the whole point is to not think about tables, rows and columns but simply objects of which state needs to be persisted.
Do I make sense?
 
John Takacs, D.P.M.
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If "it's all about cache", does that mean that only certain recurring queries are ever maintained in memory? In other words, an entire table would never persist?
 
Craig Russell
Author
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An implementation might retain the entire database contents in cache, or only the application's working set. And since JDO queries are equally suited for memory or back end, queries can be blindingly fast as well.
Just remember that JDO is a specification that allows, but doesn't require such multi-level caches. JDO is not magic. The data lives in the datastore and it must be fetched to be used. Implementations can optimize future accesses (but as has been pointed out, distributed caches can keep data around once they have been accessed once by an application).
Originally posted by John Takacs, D.P.M.:
If "it's all about cache", does that mean that only certain recurring queries are ever maintained in memory? In other words, an entire table would never persist?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic