File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Object Relational Mapping and the fly likes JDO Caching? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JDO Caching?" Watch "JDO Caching?" New topic
Author

JDO Caching?

Joshua White
Ranch Hand

Joined: Jun 04, 2001
Posts: 97
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?

Regards,

Joshua
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
Afaik JDO spec speaks about entities caching using a 2nd level cache (if I remember well CacheManager is the interface offering access to cache functionality).

./pope


blog - InfoQ.com
Joshua White
Ranch Hand

Joined: Jun 04, 2001
Posts: 97
Pardon my ignorance on caching. I have seen the term "second-level" cache before, but I am unsure what it actually means. Where can I learn more about this type of caching?

Josuha
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
A very nice entry is hosted here on JavaRanch: Caching Strategies

For implementation details you should check some of the OS caching solutions.

./pope
Joshua White
Ranch Hand

Joined: Jun 04, 2001
Posts: 97
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?

Joshua
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
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 .

./pope
Robin Roos
author
Greenhorn

Joined: Nov 01, 2004
Posts: 15
Hi

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>
Thomas Whitmore
Ranch Hand

Joined: Aug 05, 2004
Posts: 33
Hi Joshua,

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.


Regards,
Thomas Whitmore
www.powermapjdo.com
Eusebio Floriano
Ranch Hand

Joined: Mar 07, 2004
Posts: 235
IS there any benchmark comparing the efficiency of hibernate caching and JDO caching ?


SCJP 1.4 / 5.0 - SCBCD 1.3 - SCWCD 1.4 - IBM 484
Alexandru Popescu
Ranch Hand

Joined: Jul 12, 2004
Posts: 995
As far as i am aware, the caching solutions are pretty much the same in both solutions, so I guess you should take a look at different caching solutions available.

./pope
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JDO Caching?
 
Similar Threads
JDO API
Journal Article - Java Data Objects - An Introduction
JDO and concurrency
JDO API
Persistence frameworks? Who needs them anyway?