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.
        
This plug-in property can be used to identify the name of the master slice. Master slice is used when a primary key is to be generated from a database sequence.
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 receives 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-complaint 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-complaint JDBC driver.