| <html><head> |
| <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> |
| <title>Chapter 15. Optimization Guidelines</title><base href="display"><link rel="stylesheet" type="text/css" href="css/docbook.css"><meta name="generator" content="DocBook XSL-NS Stylesheets V1.76.1"><link rel="home" href="manual.html" title="Apache OpenJPA 2.4 User's Guide"><link rel="up" href="ref_guide.html" title="Part 3. Reference Guide"><link rel="prev" href="ref_guide_integration_dbcp.html" title="2. Apache Commons DBCP"><link rel="next" href="ref_guide_instrumentation.html" title="Chapter 16. Instrumentation"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 15. |
| Optimization Guidelines |
| </th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ref_guide_integration_dbcp.html">Prev</a> </td><th width="60%" align="center">Part 3. Reference Guide</th><td width="20%" align="right"> <a accesskey="n" href="ref_guide_instrumentation.html">Next</a></td></tr></table><hr></div><div class="chapter" title="Chapter 15. Optimization Guidelines" id="ref_guide_optimization"><div class="titlepage"><div><div><h2 class="title">Chapter 15. |
| Optimization Guidelines |
| </h2></div></div></div> |
| |
| <a class="indexterm" name="d5e17243"></a> |
| <p> |
| There are numerous techniques you can use in order to ensure that OpenJPA |
| operates in the fastest and most efficient manner. Following are some |
| guidelines. Each describes what impact it will have on performance and |
| scalability. Note that general guidelines regarding performance or scalability |
| issues are just that - guidelines. Depending on the particular characteristics |
| of your application, the optimal settings may be considerably different than |
| what is outlined below. |
| </p> |
| <p> |
| In the following table, each row is labeled with a list of italicized keywords. |
| These keywords identify what characteristics the row in question may improve |
| upon. Many of the rows are marked with one or both of the <span class="emphasis"><em>performance |
| </em></span> and <span class="emphasis"><em>scalability</em></span> labels. It is important to bear |
| in mind the differences between performance and scalability (for the most part, |
| we are referring to system-wide scalability, and not necessarily only |
| scalability within a single JVM). The performance-related hints will probably |
| improve the performance of your application for a given user load, whereas the |
| scalability-related hints will probably increase the total number of users that |
| your application can service. Sometimes, increasing performance will decrease |
| scalability, and vice versa. Typically, options that reduce the amount of work |
| done on the database server will improve scalability, whereas those that push |
| more work onto the server will have a negative impact on scalability. |
| </p> |
| <div class="table"><a name="d5e17249"></a><p class="title"><b>Table 15.1. |
| Optimization Guidelines |
| </b></p><div class="table-contents"> |
| |
| <table summary="
 Optimization Guidelines
 " border="1"><colgroup><col align="left" class="name"><col align="left" class="desc"></colgroup><tbody valign="top"><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use a connection pool |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| OpenJPA's built-in datasource does not perform connection pooling or |
| prepared statement caching, but it can use Apache Commons DBCP for connection |
| pooling if it is provided on the classpath. Check out the |
| <a class="link" href="ref_guide_dbsetup.html#ref_guide_dbsetup_builtin" title="1. Using the OpenJPA DataSource">DriverDataSource</a> |
| section, which describes how to use and configure Commons DBCP. |
| Also, you can manually plug in a third-party pooling datasource like |
| <a class="link" href="ref_guide_integration_dbcp.html" title="2. Apache Commons DBCP">Apache Commons DBCP</a>, |
| included in the binary distribution and openjpa-all artifact, which may |
| drastically improve application performance. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Optimize database indexes |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| The default set of indexes created by OpenJPA's mapping tool may not always be |
| the most appropriate for your application. Manually setting indexes in your |
| mapping metadata or manually manipulating database indexes to include |
| frequently-queried fields (as well as dropping indexes on rarely-queried |
| fields) can yield significant performance benefits. |
| <p> |
| A database must do extra work on insert, update, and delete to maintain an |
| index. This extra work will benefit selects with WHERE clauses, which will |
| execute much faster when the terms in the WHERE clause are appropriately |
| indexed. So, for a read-mostly application, appropriate indexing will slow down |
| updates (which are rare) but greatly accelerate reads. This means that the |
| system as a whole will be faster, and also that the database will experience |
| less load, meaning that the system will be more scalable. |
| </p> |
| <p> |
| Bear in mind that over-indexing is a bad thing, both for scalability and |
| performance, especially for applications that perform lots of inserts, updates, |
| or deletes. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| JVM optimizations |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, reliability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Manipulating various parameters of the Java Virtual Machine (such as hotspot |
| compilation modes and the maximum memory) can result in performance |
| improvements. For more details about optimizing the JVM execution environment, |
| please see <a class="ulink" href="http://www.oracle.com/technetwork/java/hotspotfaq-138619.html" target="_top">http://www.oracle.com/technetwork/java/hotspotfaq-138619.html</a>. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use the data cache |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Using OpenJPA's <a class="link" href="ref_guide_caching.html#ref_guide_cache" title="1. Data Cache">data and query caching</a> |
| features can often result in a dramatic improvement in performance. |
| Additionally, these caches can significantly reduce the amount of load on |
| the database, increasing the scalability characteristics of your application. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Set <code class="literal">LargeTransaction</code> to true, |
| or set <code class="literal"> PopulateDataCache</code> to |
| false |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance vs. scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| When using OpenJPA's <a class="link" href="ref_guide_caching.html#ref_guide_cache" title="1. Data Cache">data caching</a> |
| features in a transaction that will delete, modify, or create a very large |
| number of objects you can set <code class="literal">LargeTransaction</code> to true and |
| perform periodic flushes during your transaction to reduce its memory |
| requirements. See the Javadoc: |
| <a class="ulink" href="../javadoc/org/apache/openjpa/persistence/OpenJPAEntityManager.html" target="_top"> |
| OpenJPAEntityManager.setTrackChangesByType</a>. Note that transactions in |
| large mode have to more aggressively flush items from the data cache. |
| <p> |
| If your transaction will visit objects that you know are very unlikely to be |
| accessed by other transactions, for example an exhaustive report run only once a |
| month, you can turn off population of the data cache so that the transaction |
| doesn't fill the entire data cache with objects that won't be accessed again. |
| Again, see the Javadoc: |
| <a class="ulink" href="../javadoc/org/apache/openjpa/persistence/OpenJPAEntityManager.html" target="_top"> |
| OpenJPAEntityManager.setPopulateDataCache</a> |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Run the OpenJPA enhancer on your persistent classes, |
| either at build-time or deploy-time. |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability, memory footprint</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| OpenJPA performs best when your persistent classes have been run through the |
| OpenJPA post-compilation bytecode enhancer. When dealing with enhanced classes, |
| OpenJPA can make a number of assumptions that reduce memory footprint and |
| accelerate persistent data access. When evaluating OpenJPA's performance, |
| build-time or deploy-time enhancement should be enabled. See |
| <a class="xref" href="ref_guide_pc_enhance.html" title="2. Enhancement">Section 2, “ |
| Enhancement |
| ”</a> for details. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Disable logging, performance tracking |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Developer options such as verbose logging and the JDBC performance tracker can |
| result in serious performance hits for your application. Before evaluating |
| OpenJPA's performance, these options should all be disabled. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Set <code class="literal">IgnoreChanges</code> to true, or |
| set <code class="literal">FlushBeforeQueries</code> to true |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance vs. scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| When both the <a class="link" href="ref_guide_conf_openjpa.html#openjpa.IgnoreChanges" title="5.37. openjpa.IgnoreChanges"><code class="literal"> |
| openjpa.IgnoreChanges</code></a> and |
| <a class="link" href="ref_guide_conf_openjpa.html#openjpa.FlushBeforeQueries" title="5.36. openjpa.FlushBeforeQueries"><code class="literal">openjpa.FlushBeforeQueries |
| </code></a> properties are set to false, OpenJPA needs to consider |
| in-memory dirty instances during queries. This can sometimes result in OpenJPA |
| needing to evaluate the entire extent objects in order to return the correct |
| query results, which can have drastic performance consequences. If it is |
| appropriate for your application, configuring <code class="literal">FlushBeforeQueries |
| </code> to automatically flush before queries involving dirty objects will |
| ensure that this never happens. Setting <code class="literal">IgnoreChanges</code> to |
| false will result in a small performance hit even if <code class="literal">FlushBeforeQueries |
| </code> is true, as incremental flushing is not as efficient overall as |
| delaying all flushing to a single operation during commit. |
| <p> |
| Setting <code class="literal">IgnoreChanges</code> to <code class="literal">true</code> will help |
| performance, since dirty objects can be ignored for queries, meaning that |
| incremental flushing or client-side processing is not necessary. It will also |
| improve scalability, since overall database server usage is diminished. On the |
| other hand, setting <code class="literal">IgnoreChanges</code> to <code class="literal">false</code> |
| will have a negative impact on scalability, even when using automatic flushing |
| before queries, since more operations will be performed on the database server. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Configure <code class="literal">openjpa.ConnectionRetainMode |
| </code> appropriately |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance vs. scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| The <a class="link" href="ref_guide_conf_openjpa.html#openjpa.ConnectionRetainMode" title="5.25. openjpa.ConnectionRetainMode"><code class="literal">ConnectionRetainMode |
| </code></a> configuration option controls when OpenJPA will obtain a |
| connection, and how long it will hold that connection. The optimal settings for |
| this option will vary considerably depending on the particular behavior of |
| your application. You may even benefit from using different retain modes for |
| different parts of your application. |
| <p> |
| The default setting of <code class="literal">on-demand</code> minimizes the amount of time |
| that OpenJPA holds onto a datastore connection. This is generally the best |
| option from a scalability standpoint, as database resources are held for a |
| minimal amount of time. However, if you are not using connection pooling, or |
| if your <code class="classname">DataSource</code> is not efficient at managing its |
| pool, then this default value could cause undesirable pool contention. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use flat inheritance |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability vs. disk space</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Mapping inheritance hierarchies to a single database table is faster for most |
| operations than other strategies employing multiple tables. If it is |
| appropriate for your application, you should use this strategy whenever |
| possible. |
| <p> |
| However, this strategy will require more disk space on the database side. Disk |
| space is relatively inexpensive, but if your object model is particularly large, |
| it can become a factor. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| High sequence increment |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| For applications that perform large bulk inserts, the retrieval of sequence |
| numbers can be a bottleneck. Increasing sequence allocation sizes can reduce or eliminate |
| this bottleneck. In some cases, implementing your own sequence factory can |
| further optimize sequence number retrieval. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use optimistic transactions |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Using datastore transactions translates into pessimistic database row locking, |
| which can be a performance hit (depending on the database). If appropriate for |
| your application, optimistic transactions are typically faster than datastore |
| transactions. |
| <p> |
| Optimistic transactions provide the same transactional guarantees as datastore |
| transactions, except that you must handle a potential optimistic verification |
| exception at the end of a transaction instead of assuming that a transaction |
| will successfully complete. In many applications, it is unlikely that different |
| concurrent transactions will operate on the same set of data at the same time, |
| so optimistic verification increases the concurrency, and therefore both the |
| performance and scalability characteristics, of the application. A common |
| approach to handling optimistic verification exceptions is to simply present the |
| end user with the fact that concurrent modifications happened, and require that |
| the user redo any work. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use query aggregates and projections |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Using aggregates to compute reporting data on the database server can |
| drastically speed up queries. Similarly, using projections when you are |
| interested in specific object fields or relations rather than the entire object |
| state can reduce the amount of data OpenJPA must transfer from the database to |
| your application. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Always close resources |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| <p> |
| Under certain settings, <code class="classname"> EntityManager</code> s, OpenJPA |
| <code class="classname">Extent</code> iterators, and <code class="classname">Query</code> |
| results may be backed by resources in the database. |
| </p> |
| <p> |
| For example, if you have configured OpenJPA to use scrollable cursors and lazy |
| object instantiation by default, each query result will hold open a <code class="classname"> |
| ResultSet</code> object, which, in turn, will hold open a <code class="classname"> |
| Statement</code> object (preventing it from being re-used). Garbage |
| collection will clean up these resources, so it is never necessary to explicitly |
| close them, but it is always faster if it is done at the application level. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use detached state managers |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| <p> |
| Attaching and even persisting instances can be more efficient when your detached |
| objects use detached state managers. By default, OpenJPA does not use detached |
| state managers when serializing an instance across tiers. See |
| <a class="xref" href="ref_guide_remote.html#ref_guide_detach_graph" title="1.3. Defining the Detached Object Graph">Section 1.3, “ |
| Defining the Detached Object Graph |
| ”</a> for how to force OpenJPA to use |
| detached state managers across tiers, and for other options for more efficient |
| attachment. |
| </p> |
| <p> |
| The downside of using a detached state manager across tiers is that your |
| enhanced persistent classes and the OpenJPA libraries must be available on the |
| client tier. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Utilize the <code class="classname">EntityManager</code> |
| cache |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| When possible and appropriate, re-using <code class="classname">EntityManager</code>s |
| and setting the <a class="link" href="ref_guide_conf_openjpa.html#openjpa.RetainState" title="5.63. openjpa.RetainState"><code class="literal">RetainState |
| </code></a> configuration option to <code class="literal">true</code> may result in |
| significant performance gains, since the <code class="classname">EntityManager</code>'s |
| built-in object cache will be used. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Enable multithreaded operation only when necessary |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| OpenJPA respects the <a class="link" href="ref_guide_conf_openjpa.html#openjpa.Multithreaded" title="5.50. openjpa.Multithreaded"><code class="literal"> |
| openjpa.Multithreaded</code></a> option in that it does not impose as |
| much synchronization overhead for applications that do not set this value to |
| <code class="literal">true</code>. If your application is guaranteed to only use |
| single-threaded access to OpenJPA resources and persistent objects, leaving |
| this option as <code class="literal">false</code> will reduce synchronization overhead, |
| and may result in a modest performance increase. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Enable large data set handling |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| If you execute queries that return large numbers of objects or have relations |
| (collections or maps) that are large, and if you often only access parts of |
| these data sets, enabling <a class="link" href="ref_guide_dbsetup_lrs.html" title="10. Large Result Sets">large result |
| set handling</a> where appropriate can dramatically speed up your |
| application, since OpenJPA will bring the data sets into memory from the |
| database only as necessary. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Disable large data set handling |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| If you have enabled scrollable result sets and on-demand loading but you do not |
| require it, consider disabling it again. Some JDBC drivers and databases |
| (SQL Server for example) are much slower when used with scrolling result sets. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use the <code class="classname">DynamicSchemaFactory</code> |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, validation</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| If you are using an <a class="link" href="ref_guide_conf_jdbc.html#openjpa.jdbc.SchemaFactory" title="6.13. openjpa.jdbc.SchemaFactory"><code class="literal"> |
| openjpa.jdbc.SchemaFactory</code></a> setting of something other than |
| the default of <code class="literal">dynamic</code>, consider switching back. While other |
| factories can ensure that object-relational mapping information is valid when |
| a persistent class is first used, this can be a slow process. Though the |
| validation is only performed once for each class, switching back to the |
| <code class="classname">DynamicSchemaFactory</code> can reduce the warm-up time for |
| your application. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Do not use XA transactions |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| <a class="link" href="ref_guide_enterprise_xa.html" title="3. XA Transactions">XA transactions</a> can be orders of |
| magnitude slower than standard transactions. Unless distributed transaction |
| functionality is required by your application, use standard transactions. |
| <p> |
| Recall that XA transactions are distinct from managed transactions - managed |
| transaction services such as that provided by EJB declarative transactions can |
| be used both with XA and non-XA transactions. XA transactions should only be |
| used when a given business transaction involves multiple different transactional |
| resources (an Oracle database and an IBM transactional message queue, for |
| example). |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use <code class="classname">Set</code>s instead of |
| <code class="classname">List/Collection</code>s |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| There is a small amount of extra overhead for OpenJPA to maintain collections |
| where each element is not guaranteed to be unique. If your application does |
| not require duplicates for a collection, you should always declare your |
| fields to be of type <code class="classname">Set, SortedSet, HashSet,</code> or |
| <code class="classname">TreeSet</code>. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use query parameters instead of encoding search |
| data in filter strings |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| If your queries depend on parameter data only known at runtime, you should use |
| query parameters rather than dynamically building different query strings. |
| OpenJPA performs aggressive caching of query compilation data, and the |
| effectiveness of this cache is diminished if multiple query filters are used |
| where a single one could have sufficed. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Tune your fetch groups appropriately |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| The <a class="link" href="ref_guide_fetch.html" title="7. Fetch Groups">fetch groups</a> used when loading an |
| object control how much data is eagerly loaded, and by extension, which fields |
| must be lazily loaded at a future time. The ideal fetch group configuration |
| loads all the data that is needed in one fetch, and no extra fields - this |
| minimizes both the amount of data transferred from the database, and the |
| number of trips to the database. |
| <p> |
| If extra fields are specified in the fetch groups (in particular, large fields |
| such as binary data, or relations to other persistence-capable objects), then |
| network overhead (for the extra data) and database processing (for any necessary |
| additional joins) will hurt your application's performance. If too few fields |
| are specified in the fetch groups, then OpenJPA will have to make additional |
| trips to the database to load additional fields as necessary. |
| </p> |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Use eager fetching |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Using <a class="link" href="ref_guide_perfpack_eager.html" title="8. Eager Fetching">eager fetching</a> when |
| loading subclass data or traversing relations for each instance in a large |
| collection of results can speed up data loading by orders of magnitude. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Disable BrokerImpl finalization |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>performance, scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| Outside of a Java EE application server or other JPA persistence container, |
| OpenJPA's EntityManagers use finalizers to ensure that resources |
| get cleaned up. If you are properly managing your resources, this finalization |
| is not necessary, and will introduce unneeded synchronization, leading to |
| scalability problems. You can disable this protective behavior by setting the |
| <code class="literal">openjpa.BrokerImpl</code> property to |
| <code class="literal">non-finalizing</code>. See <a class="xref" href="ref_guide_runtime.html#ref_guide_runtime_broker_finalization" title="1.1. Broker Finalization">Section 1.1, “ |
| Broker Finalization |
| ”</a> for details. |
| </td></tr><tr><td align="left" valign="top"> |
| <span class="bold"><strong> |
| Preload MetaDataRepository |
| </strong></span> |
| <p> |
| <span class="emphasis"><em>scalability</em></span> |
| </p> |
| </td><td align="left" valign="top"> |
| By default, the MetaDataRepository is lazily loaded which means that fair amounts of locking |
| is used to ensure that metadata is processed properly. Enabling preloading allows OpenJPA to |
| load metadata upfront and remove locking. See <a class="xref" href="ref_guide_meta_repository.html" title="2. Metadata Repository">Section 2, “Metadata Repository”</a> for details. |
| </td></tr></tbody></table> |
| </div></div><br class="table-break"> |
| </div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ref_guide_integration_dbcp.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ref_guide.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ref_guide_instrumentation.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">2. |
| Apache Commons DBCP |
| </td><td width="20%" align="center"><a accesskey="h" href="manual.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 16. |
| Instrumentation |
| </td></tr></table></div></body></html> |