System Configuration Diagram

  Tablespace sizes were increased to support the Injection rate.
  Scripts to create the DB are included in the FDA.
  Table and index initrans were modified.
  The M_WORKORDER table was horizontally partitioned.

  The load program was not modified.

  The following Beans were deployed in READ_COMMITTED mode as per the benchmark
  requirement:
  Mfg      - AssemblyEnt, BomEnt, ComponentEnt, LargeOrderEnt, PartEnt
  Orders   - ItemEnt
  Supplier - SupplierCompEnt, SupplierEnt
  All other beans were deployed using pessimistic locking mode such that all
  selects including finders are issued with a FOR UPDATE clause in select
  statement:
  Corp     - CustomerEnt, CustomerInventoryEnt
  Mfg      - InventoryEnt, WorkOrderEnt
  Orders   - OrderEnt, OrderLineEnt
  Supplier - POEnt, POLineEnt, SComponentEnt
  Util     - SequenceEnt
  
  The ItemEnt bean was cached for 20 minute intervals by setting read-only to
  true and time-to-live to 1200000 in orders-toplink-ejb-jar.xml.

  To ensure database durability, RAID 1 (mirroring) was used for the data files
  and database Redo logs.
  
  The application server was using mirrored disks to provide durability for
  server logs and JMS persistence filestore.
  
  The RAID controller on the database and the application server machines were
  configured with Write-Through cache policy, as there was no battery backup
  unit on the controller.

  A 75 min run at Injection Rate of 670 increased storage by 1260 MB. Extrapolating
  for 24 hrs we need 24.0 GB. The system is configured with over 975 GB of storage.

  Oracle Application Server 10g uses pass-by-value as required by the EJB
  specification.

Supplier  Description                                   SKU #              Qty
--------  -------------------------------------------   ----------------   ---
Rackable Systems S3118 Storage System               S3118-L03-X5355-AS-A    1** 
Rackable Systems C2002-HPC Server               C2002-HPC-L03-X5355-AS-A    1**
Rackable Systems Platinum Support Coverage for 3 years       50-40-00003    2

Cisco     Catalyst 3560G Switch                     39-00-00177             1
Red Hat   Enterprise Linux Premium Subscription (1 Year)                    6
Oracle    Oracle Database 10g Release 2 Enterprise Edition, Per Processor    
          Unlimited Users for 3 years                                       4*
Oracle    Partitioning, Per Processor, Unlimited Users for 3 years          4* 
Oracle    Oracle Database Server Support Package for 3 years
          (Incident Server Support) 24x7x4                                  1
Oracle    Oracle Application Server 10g Release 10.1.3.2, Per Processor    
          (v10.1)                                                           4*
Oracle    Oracle Application Server Support Package for 3 years	     	
          (Incident Server Support) 24x7x4                                  1 

(* 4 = 0.50 * 8).  Explanation:  For the purposes of counting the number of
processors which require licensing, an Intel multicore chip with "n" cores
shall be determined by multiplying "n" cores by a factor of 0.50).

(** For information on Rackable Systems products used in the benchmark, please 
contact Rackable Systems: Sales 1-408-240-8300, option 2, or Email, sales@rackable.com)

  The xerces implementation version 2.6.2 from xml.apache.org was used as it
  comes packaged with Oracle Application Server 10g.
  
  Requests were sent to the Appserver over 3 netowrks using DNS round robin,
  with the database node acting as the DNS server.
  
  The driver used the following jndi.properties:
  java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactory
  java.naming.provider.url=ormi://main.spec.com:23791/SPECjAppServer
  java.naming.security.principal=oc4jadmin
  java.naming.security.credentials=welcome
  oracle.j2ee.rmi.loadBalance=lookup

On the database, incremental checkpointing ensured that no buffer will
remain dirty (in the cache) for more than the allowed time.

Oracle Application Server 10g Release 10.1.3.2 implements Recoverable Last
Resource Commit optimization where one and only one SinglePhaseResource
participates in a global transaction with one or more XAResources. This is
accomplished by emulating an XAResource to represent the 1PC resource. The
transaction manager takes the following steps when it receives a request to commit
a global transaction that includes one emulated XAResource:
1. It invokes a prepare call on each of the 2PC resources.
2. If all of the 2PC resources are successfully prepared, then commit (one-phase)
is called and the commit record is written to the commit-log, on the emulated XA
resource (database) as part of the local transaction.
3. If the 1PC on the emulated XA resource completes successfully, then the
transaction manager calls commit on each of the 2PC resources.
or:
If the 1PC on the emulated XA resource fails, then the transaction manager queries
the commit-log for transaction outcome. If the record exists, 2PC resources are
committed, otherwise 2PC Resources are aborted.
Transaction outcome after a single point of failure is guaranteed by the presence of
the commit-record in the commit log, indicating a successful transaction completion;
while a missing commit-record signifies abort. The commit record is deleted lazily
after the global transaction has committed.

The only errors in the driver error logs are the application errors generated
by this benchmark.