System Configuration Diagram

  No modifications to the schema where made.

  No modifications to the load programs were made.

  The benchmark meets the isolation level requirements by version column
    checking on entities against the database.
  The ItemEnt bean was cached for 20 minute intervals using
    the WebSphere JPA Object Cache mechanism.

  To ensure database durability, RAID10 was used for the
    database logs maintained on the external storage.
    A total of 24 x 146GB disks were used for the log.

  Over the course of a 85 minute run at an injection rate of
    2550, the database storage for database system increased by
    1.7 GB.  Given a linear scale, a 24 hour run at the same
    injection rate would increase storage for database system
    by 28.8 GB.  One RAID10 disk arrays were used to create the
    filesystem space for the database.  The array contained
    20 x 146.8GB disks providing 2936 GB of storage.

Supplier  Description                                         Product #           Qty
--------  -------------------------------------------         ----------------    ---
IBM       IBM Power 730	                                      8231-E2B             1
-            2x8-core POWER7 Processor
-            (3.55GHz 4MB L3 Cache per core)
-            128GB RAM (16x8GB DIMMS), 1x146.8GB 15k SAS HDD
-            3 Year Onsite Repair 24x7 4 Hour Response     	                     "	
IBM       AIX Standard Edition V7.1 per processor             5765-G98-0008        16
IBM       AIX 3 year support per processor                    5773-SM3-1253        16
...
IBM       BladeCenter H Chassis                               7989-BCH              1
IBM       BladeCenter PS701 Express                           8406-71Y              1
-            8-core POWER7 Processor
-            (3.0GHz 4MB L3 Cache per core)
-            128GB RAM (16x8GB DIMMS), 1x146.8GB 15k SAS HDD
-            3 Year Onsite Repair 24x7 4 Hour Response     	
IBM       DS3524 Express Dual Controller, 4 GB Cache         	1746-E4A1           1
IBM       6Gbps FC, 146.8 GB/15K HDD	                        5205                48
IBM       AIX Standard Edition V7.1 per processor             5765-G98-0008         8
IBM       AIX 3 year support per processor                    5773-SM3-1253         8
...
CDW       3Com Switch 4200G 48-Port                           1020899               1
CDW       3Com Switch 4200G 48-Port Sup 1 yr, 24x7x4          819638                1
...
IBM       IBM DB2 Workgroup Server Edition  9.7               D0A1LLL               1
-         Limited Use Socket Lic+SW Maint 12 Months
IBM       IBM DB2 Workgroup Server Edition 9.7	             E07BQLL                2
-         Limited Use Socket SW Maint Rewl 1 Anniv
IBM       WebSphere Application Server V7                     D55W8LL              16**
-           Lic+SW Maint 12 Months
IBM       WebSphere Application Server V7	             E1CBILL               32
-           SW Maint Rewl 1 Anniv
-           Fix Pack 13 (7.0.0.13)
-           PM20973
-           Feature Pack for OSGi Applications and Java Persistence API 2.0
-           OSGi & JPA Fix Pack 1.0.0.1
...
** Note:  Pricing for WebSphere is based on Processor Value Units (PVU).  Each POWER7 core is 70 PVU.

  DNS round robin load balancing was used and hosted on the database machine
  All network connections were 1Gbps

All exceptions in driver logs are from Optimistic Concurrency Checking.
These exceptions are expected in the benchmark.

The IBM DB2 Universal JDBC Drivers is a type 4 driver.

DB2 uses "Soft" checkpoint to ensure that no updates remain unflushed for
longer than the allowed time.

When DB2 UDB Server changes a database table with an update, insert, or delete
operation, the change is initially made in memory, not on disk. When there is
not enough space in the memory buffer to read in or write additional data pages,
DB2 UDB Server will make space by flushing some modified pages to disk.
Modified pages are also written to disk as part of the "Soft" checkpoint to
ensure that no updates remain unflushed for longer than the allowed time.
Before a change is made to the database, it is first recorded in the
transaction log. This ensures that the database can be recovered completely
in the event of a failure. Using the transaction log, transactions that
started but did not complete prior to a failure can be undone, and
transactions recorded as complete in the transaction log but not yet written
to disk can be redone.

DB2 UDB uses a write-ahead-logging protocol to guarantee recovery. This
protocol uses "Soft" checkpoint to write least-recently-used database pages
to disk independent of transaction commit. However, enough log information to
redo/undo the change to a database pages is committed to disk before the
database page itself is written. This protocol therefore renders checkpoint
unnecessary for DB2 UDB. For a more detailed description of the general
principles of the write-ahead-logging protocol, see the IBM research paper,
ARIES: A Transaction Recovery Method Supporting Fine Granularity Locking and
Partial Rollbacks Using Write-Ahead Logging," by C. Mohan, Database Technology
Institute, IBM Almaden Research Center. (http:// portal.acm.org/citation.cfm
?id=128770&coll=portal&dl=ACM&CFID=10343790&CFTOKEN=42047146)