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 EJB 2 Entity Beans?
1.7.4. How can I speed up my Kodo application?
1.7.5. How can I profile the performance of my application?
1.7.6. Can I customize the fields that Kodo loads when an object is first instantiated from the database?
1.7.7. 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.8. 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-session cache that is mandated by the specification. Kodo also provides a level 2 data cache that can be shared by multiple sessions and has the capability of synchronizing across a distributed system. See Section 10.1, “Data 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 the application beyond what is possible using raw JDBC.

1.7.3.

Is Kodo faster than EJB 2 Entity Beans?

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 plain Java objects, since plain objects 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 15, Optimization Guidelines.

1.7.5.

How can I profile the performance of my application?

Kodo provides a sophisticated set of management tools to analyze the behavior and performance of your application. See Chapter 12, Management and Monitoring and Chapter 13, Profiling. Also, Kodo can be used in all popular profiling applications such as OptimizeIt or JProbe.

1.7.6.

Can I customize the fields that Kodo loads when an object is first instantiated from the database?

Yes. Kodo allows the definition of custom fetch groups, which enable the application to dynamically specify which fields to instantiate eagerly. See Section 5.6, “Fetch Groups”.

1.7.7.

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. See Section 5.7, “Eager Fetching”.

1.7.8.

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 DataSource” and Section 4.2, “Using a Third-Party DataSource”.

 

Skip navigation bar   Back to Top