1.7. Performance
Prev | Chapter 1. Kodo JDO Frequently Asked Questions | Next

## 1.7. Performance

1.7.1. Does Kodo use any caching?
1.7.2. Is Kodo faster than JDBC?
1.7.3. Is Kodo faster than EJBs?
1.7.4. How can I speed up my Kodo application?
1.7.5. Can I customize the fields that Kodo loads when an object is first instantiated from the database?
1.7.6. When I traverse a relation, Kodo issues a separate statement to the database. How can I ensure that the relation is always loaded immediately?
1.7.7. Does Kodo utilize connection pooling?

1.7.1. | Does Kodo use any caching?
| Yes. Kodo has two levels of caching. The first is a per-PersistenceManager cache that is mandated by the JDO specification. Kodo also provides a level 2 cache that can be shared by multiple PersistenceManager instances and has the capability of synchronizing across a distributed system. See Section 14.3, “Datastore Cache”.
1.7.2. | Is Kodo faster than JDBC?
| A Kodo application will typically outperform a generic JDBC application, since Kodo is able to able to efficiently batch together like operations at commit time, eliminate redundant SQL, and and perform sophisticated caching. Since Kodo runs atop a JDBC driver, it will never be able to communicate with the database any faster than the JDBC driver can. However, for any operations beyond the most simplistic JDBC program, Kodo will dramatically increase the performance of any application beyond what is realisticly possible using raw JDBC.
1.7.3. | Is Kodo faster than EJBs?
| It is only meaningful to compare the performance of Kodo with that of CMP Entity Beans. While the performance of CMP beans varies depending on the application server being used, they will almost always be slower than using JDO persistent objects, since JDO does not incur the heavy method invocation overhead that penalizes all EJBs.
1.7.4. | How can I speed up my Kodo application?
| Kodo provides a wide variety of configuration options and API extensions to fine tune your applications performance. For an overview of common optimization techniques, see Chapter 16, Optimization Techniques.
1.7.5. | Can I customize the fields that Kodo loads when an object is first instantiated from the database?
| Yes. JDO defines the notion of a "default-fetch-group", which enables the application to specify the fields that will be loaded whenever a persistent instance is instantiated from the database. Adding to that, Kodo provides extensions that allow the definition of custom fetch groups, which enable the application to dynamically specify which fields to instantiate eagerly. See Section 10.5, “Fetch Configuration”.
1.7.6. | When I traverse a relation, Kodo issues a separate statement to the database. How can I ensure that the relation is always loaded immediately?
| Relations, like any other fields, can be added to the default fetch group, which will cause Kodo to attempt to efficiently traverse the relation when the owning persistent instance is first instantiated from the database.
1.7.7. | Does Kodo utilize connection pooling?
| Kodo provides its own built-in connection pooling framework. Additionally, Kodo can be integrated with any third-party connection pool that implements the javax.sql.DataSource interface (including the connection pools that are provided with all known application servers). See Section 4.1, “Using the Kodo JDO DataSource” and Section 4.2, “Using a Third-Party DataSource”.

Prev | Up | Next
1.6. Productivity tools | Home | 1.8. Scalability