Forums Register Login

The price of JDO

+Pie Number of slices to send: Send
 

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.

 
+Pie Number of slices to send: Send
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.

 
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
 

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?
+Pie Number of slices to send: Send
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?

 
+Pie Number of slices to send: Send
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?
+Pie Number of slices to send: Send
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?

 
If you send is by car it's a shipment, but if by ship it's cargo. This tiny ad told me:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 728 times.
Similar Threads
JDO, Hibernate, Castor
Welcome David Jordan and Craig Russell to our Book Promotion of the Week
JDO and transactions
Using JDO with an existing DB schema
JDO
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 23:04:44.