I was looking at JDO several weeks ago. I noticed that several vendors add "Performance Packs" to their standard products. These enhancements are supposed to be in addition to the caching required in the JDO specification.
Why should I consider looking into these performance packs is caching is required by the JDO specification? What is the difference?
For implementation details you should check some of the OS caching solutions.
Joined: Jun 04, 2001
Thanks for the link!
Back to JDO... If JDO supports caching by default, why buy a "performance pack"? Is the standard caching deficientin some manner? Should I consider this?
Joined: Jul 12, 2004
I am not aware of these performance packs. Maybe they contain some other features to enhance your application. JDO is just a specification. JDO talks only about L2 cache and not how it should be done. So I guess you should give 'em a try .
JDO requires a cache per PersistenceManager. Each PM manages its cache, and the lifecycles and state transitions of objects in the cache are specified in significant detail. In one PM's cache, at most one object may exist with a given persistent identity. So if you get a reference to the *same* persistent Employee object within one PM, no matter how you got that reference you are guarranteed that you all references will address the *same* Java object (i.e. == will hold true).
A Second Level cache ("Level-2" cache, "L2" cache) manages instances across multiple PMs, usually on a per-PersistenceManagerFactory basis.
The JDO 2.0 specification includes an interface (CacheManager) for interacting with an L2 cache should it exist, with methods to pin/unpin objects, etc. If no L2 cache is present then these operations are guarranteed to be NOPs, so the application code is portable and does not rely on the presence of an L2 cache.
That's all the spec says about L2 cache. Kodo comes with an L2 cache implementation which makes access to objects more efficient, caches compiled queries, caches fully iterated query results, etc. The basic mechanism is eviction-based. For even more scalability just plug in Coherence.
Does that help?
Kind regards, Robin.
Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0321123808/ref=jranch-20" target="_blank" rel="nofollow">Java Data Objects</a>
Transactional work with JDO is done in the context of a persistenceManager 'session'. This obviously manages objects and identities, specific to that session/ transaction, in what could be called a cache.
What you're asking about is the wider case, where some application data may be cacheable/ shareable between transactions; eg that old chestnut, the Product table.
Caching at this level can substantially improve 'lookup' performance on this kind of data, and work best where updates are infrequent or all performed thru the same JDO layer on the same JVM.
Beyond caching, are performance features to retrieve referenced/ plural data and structures from 'bulk' database queries. These provide a mechanism for large data which can provide performance without relying on high frequencies of repetition.
Anyway both of these are useful performance tuning. Caching and bulk retrieve are complementary and can be combined, you can achieve >1500 rows per second with even a Java db on moderate hardware. Let me know if this answers your questions.