JPOX provides 4 PersistenceManagerFactory properties org.jpox.autoCreateSchema, org.jpox.autoCreateTables org.jpox.autoCreateColumns, and org.jpox.autoCreateConstraints that allow creation of the datastore tables. This can cause performance issues at startup. We recommend setting these to false at runtime, and instead using SchemaTool to generate any required database schema before running JPOX.

The creation of a PersistenceManagerFactory is expensive in terms of time. You should aim to use as few as possible, and preferably a single factory per datastore. You can also improve startup speed by setting the property org.jpox.autoStartMechanism to None. This means that it won't try to load up the classes (or better said the metadata of the classes) handled the previous time that this schema was used. If this isn't an issue for your application then you can make this change. Please refer to the Auto-Start Mechanism for full details.

Some RDBMS (such as Oracle) have trouble returning information across multiple catalogs/schemas and so, when JPOX starts up and tries to obtain information about the existing tables, it can take some time. This is easily remedied by specifying the catalog/schema name to be used - either for the PMF as a whole (using the PMF properties javax.jdo.mapping.Catalog, javax.jdo.mapping.Schema) or for the package/class using attributes in the MetaData. This subsequently reduces the amount of information that the RDBMS needs to search through and so can give significant speed ups when you have many catalogs/schemas being managed by the RDBMS.

JPOX provides 3 PersistenceManagerFactory properties org.jpox.validateTables, org.jpox.validateConstraints org.jpox.validateColumns that enforce strict validation of the datastore tables against the Meta-Data defined tables. This can cause performance issues at startup. In general this should be run only at schema generation, and should be turned off for production usage. Set all of these properties to false. In addition there is a PMF property org.jpox.rdbms.CheckExistsTablesOrViews which checks whether the tables/views that the classes map onto are present in the datastore. This could also be set to false if you require fast start-up.

JPOX, by default, will allocate connections when they are required. It then will close the connection. In addition, when it needs to perform something via JDBC it will allocate a PreparedStatement, and then discard the statement after use. This can be inefficient relative to a database connection and statement pooling facility such as Apache DBCP. With Apache DBCP a Connection is allocated when required and then when it is closed the Connection isn't actually closed but just saved in a pool for the next request that comes in for a Connection. This saves the time taken to establish a Connection and hence can give performance speed ups the order of maybe 30% or more. You can read about how to enable connection pooling with JPOX in the Connection Pooling Guide.

JPOX verifies if newly persisted objects are memory reachable on commit, if they are not, they are removed from the database. This process mirrors the garbage collection, where objects not referenced are garbage collected or removed from memory. Reachability is expensive because it traverses the whole object tree and may require reloading data from database. If reachability is not needed by your application, you should disable it. To disable reachability set to false the PMF property org.jpox.persistenceByReachabilityAtCommit.

JPOX provides a series of identity generators (POID Generators) for generation of identity values. These can have an impact on the performance depending on the choice of generator, and also on the configuration of the generator.

• The max strategy should not really be used for production since it makes a separate DB call for each insertion of an object. Something like the increment strategy should be used instead. Better still would be to choose native and let JPOX decide for you.
• The sequence strategy allows configuration of the datastore sequence. The default can be non-optimum. As a guide, you can try setting key-cache-size to 10 and key-increment-by to 10.

The native identity generator value is the recommended choice since this will allow JPOX to decide which identity generator is best for the RDBMS in use.

JPOX has 2 ways of handling calls to SCO Collections/Maps. The original method (the default until 1.1.0-beta-1) was to pass all calls through to the datastore. The second method (which is now the default) is to cache the collection/map elements/keys/values. This second method will read the elements/keys/values once only and thereafter use the internally cached values. This second method gives significant performance gains relative to the original method. You can configure the handling of collections/maps as follows :-

• Globally for the PersistenceManagerFactory - this is controlled by setting the PMF property org.jpox.cache.collections. Set it to true for caching the collections, and false to pass through to the datastore.
• For the specific Collection/Map - this overrides the global PMF setting and is controlled by adding a MetaData <collection> or <map> extension cache. Set it to true to cache the collection data, and false to pass through to the datastore.

The second method also allows a finer degree of control. This allows the use of lazy loading of data, hence elements will only be loaded if they are needed. You can configure this as follows :-

• Globally for the PersistenceManagerFactory - this is controlled by setting the PMF property org.jpox.cache.collections.lazy. Set it to true to use lazy loading, and set it to false to load the elements when the collection/map is initialised.
• For the specific Collection/Map - this overrides the global PMF setting and is controlled by adding a MetaData <collection> or <map> extension cache-lazy-loading. Set it to true to use lazy loading, and false to load once at initialisation.

NontransactionalRead has advantages and disadvantages in performance and data freshness in cache. In NontransactionalRead=true mode, the PersistenceManager is able to read objects outside a transaction. The objects read are held cached by the PersistenceManager. The second time a user application requests the same objects from the PersistenceManager they are retrieved from cache. The time spent reading the object from cache is minimum, but the objects may become stale and not represent the database status. If fresh values need to be loaded from the database, then the user application should first call refresh on the object.

Another disadvantage of NontransactionalRead=true mode is due to each operation realized opens a new database connection, but it can be minimized with the use of connection pools.

Reading objects outside a transaction and PersistenceManager is a trivial task, but performed in a certain manner can determine the application performance. The objective here is not give you an absolute response on the subject, but point out the benefits and drawbacks for the many possible solutions.

• Use makeTransient method.

  Object pc = null;
  try
  {
      PersistenceManager pm = pmf.getPersistenceManager();
      pm.currentTransaction().begin();
  
      //retrieve in some way the object, query, getObjectById, etc
      pc = pm.getObjectById(id);
      pm.makeTransient(pc);    
  
      pm.currentTransaction().commit();
  }
  finally
  {
      pm.close();
  }
  //read the persistent object here
  System.out.prinln(pc.getName());
  

• Use RetainValues=true.

  Object pc = null;
  try
  {
      PersistenceManager pm = pmf.getPersistenceManager();
      pm.currentTransaction().setRetainValues(true);
      pm.currentTransaction().begin();
  
      //retrieve in some way the object, query, getObjectById, etc
      pc = pm.getObjectById(id);
  
      pm.currentTransaction().commit();
  }
  finally
  {
      pm.close();
  }
  //read the persistent object here
  System.out.prinln(pc.getName());
  

• Use detachCopy method.

  Object copy = null;
  try
  {
      PersistenceManager pm = pmf.getPersistenceManager();
      pm.currentTransaction().begin();
  
      //retrieve in some way the object, query, getObjectById, etc
      Object pc = pm.getObjectById(id);
      copy = pm.detachCopy(pc);    
  
      pm.currentTransaction().commit();
  }
  finally
  {
      pm.close();
  }
  //read or change the persistent copy here
  System.out.prinln(copy.getName());
  
  

The most expensive in terms of performance is the detachment because it makes copies of persistent objects. The advantage of detachment is that changes made outside the transaction can be futher used to update the database in a new transaction. The other methods also allow changes outside of the transaction, but the changed instances can't be used to update the database.

In RetainValues=true and makeTransient no object copies are made and the object values are set down in instances when the PersistenceManager disassociates them. Both methods are equivalent in performance, however the makeTransient method will set the values of the object during the instant the makeTransient method is invoked, and the RetainValues=true will set values of the object during commit.

The bottom line is to not use detachment if instances will only be used to read values.

I/O consumes a huge slice of the total processing time. Therefore it is recommended to reduce or disable logging in production. To disable the logging set the JPOX category to OFF in the Log4j configuration. See Logging for more information.

log4j.category.JPOX=OFF