This mandatory plug-in property determines how newly persistent instances are distributed across individual slices. The value of this property is a fully-qualified class name that implements org.apache.openjpa.slice.DistributionPolicy interface.

This boolean plug-in property controls the behavior when one or more slice can not be connected or unavailable for some other reasons. If true, the unreachable slices are ignored. If false then any unreachable slice will raise an exception during startup.

By default this value is set to false i.e. all configured slices must be available.

The user application often directs OpenJPA to generate primary keys for persistence instances automatically or from a specific database sequence. For such primary key value generation strategy where a database instance is required, Slice uses a designated slice referred as master slice.

The master slice can be specified explicitly via openjpa.slice.Master property and whose value is one of the configured slice names. If this property is not explicitly specified then, by default, the master slice is the first slice in the list of configured slice names.

This plug-in property can be used to register the logical slice names. The value of this property is comma-separated list of slice names. The ordering of the names in this list is significant because DistributionPolicy and ReplicationPolicy receive the input argument of the slice names in the same order.

If logical slice names are not registered explicitly via this property, then all logical slice names available in the persistence unit are registered. The ordering of the slice names in this case is alphabetical.

If logical slice names are registered explicitly via this property, then any logical slice that is available in the persistence unit but excluded from this list is ignored.

This plug-in property determines the nature of thread pool being used for database operations such as query or flush on individual slices. The value of the property is a fully-qualified class name that implements java.util.concurrent.ExecutorService interface. Two pre-defined pools can be chosen via their aliases namely fixed or cached.

The pre-defined alias cached activates a cached thread pool. A cached thread pool creates new threads as needed, but will reuse previously constructed threads when they are available. This pool is suitable in scenarios that execute many short-lived asynchronous tasks. The way Slice uses the thread pool to execute database operations is akin to such scenario and hence cached is the default value for this plug-in property.

The fixed alias activates a fixed thread pool. The fixed thread pool can be further parameterized with CorePoolSize, MaximumPoolSize, KeepAliveTime and RejectedExecutionHandler. The meaning of these parameters are described in JavaDoc. The users can exercise finer control on thread pool behavior via these parameters. By default, the core pool size is 10, maximum pool size is also 10, keep alive time is 60 seconds and rejected execution is aborted.

Both of the pre-defined aliases can be parameterized with a fully-qualified class name that implements java.util.concurrent.ThreadFactory interface.

This plug-in property determines the policy for transaction commit across multiple slices. The value of this property is a fully-qualified class name that implements javax.transaction.TransactionManager interface.

Three pre-defined policies can be chosen by their aliases namely default, xa and jndi.

The default policy employs a Transaction Manager that commits or rolls back transaction on individual slices without a two-phase commit protocol. It does not guarantee atomic nature of transaction across all the slices because if one or more slice fails to commit, there is no way to rollback the transaction on other slices that committed successfully.

The xa policy employs a Transaction Manager that that commits or rolls back transaction on individual slices using a two-phase commit protocol. The prerequisite to use this scheme is, of course, that all the slices must be configured to use XA-compliant JDBC driver.

The jndi policy employs a Transaction Manager by looking up the JNDI context. The prerequisite to use this transaction manager is, of course, that all the slices must be configured to use XA-compliant JDBC driver.