Performance enhancements

Improved INVENTORY table concurrency

When the Non-ATP inventory model is used, database update locks are held on INVENTORY table rows until the end of the OrderProcess transaction. The locks block other Orders for the same items from being processed concurrently.

In Fix Pack 7, a new "updateImmediately" configuration is introduced. INVENTORY Update locks are not obtained in the OrderProcess transaction. Instead, the INVENTORY rows are updated in a separate, much shorter transaction, and are committed as soon as possible. If the OrderProcess transaction is rolled back, then the INVENTORY updates are reversed, also in a separate transaction. Since the locks are held for a shorter time, this configuration can reduce response times when multiple shoppers buy the same item at the same time.

To configure this new behavior, add the following to the InstanceProperties tag in the wc-server.xml instance configuration file: <com.ibm.commerce.fulfillment.commands.InventoryUpdateHelper updateImmediately="true"/>

Improved performance for WebSphere Commerce search

• The Aurora starter store is optimized for search-based navigation to improve processing times.
• The Business Object Document (BOD) payload is reduced for navigation and searching. This payload ensures that the data that is being returned is only the data that is required for requests.
• The storefront overall cache-hit ratio is improved. This improvement is achieved by taking advantage of dynamic caching.
• The Knowledge Center documentation is improved to include search profiles and their performance guidelines. These profiles and guidelines ensure that store developers can optimize search performance in the storefront.
• The need for full reindexing is reduced. That is, almost all common business update operations through Management Center can now be converted into a delta update on the search index. These delta updates can reduce the availability delay of pending changes because of index updates.
• Workspace store preview response time is improved. Store preview is now driven by the WebSphere Commerce search engine through the storefront. In previous versions, store preview was driven by database views in the workspace.

e-Marketing Spot storefront presentation performance

stagingprop utility enhancements

• Improved logging and tracing for better troubleshooting. A summary report is now included at the end of the stagingprop log. Also, stagingprop now supports three levels of logging.
• Reduced the number of I/O operations against the database by increasing the number of records fetched and updated at a time.
• Added two database indexes to the STAGLOG table to improve fetch performance.
• Improved error tolerance during consolidation and propagation.
• Enhanced logic for Cyclic Reuse of Unique Keys. Value that is specified in UPDATABLE_UK_COL column in STGSITETAB and STGMERTAB tables is now manipulated for efficient resolution of CRUK.

Performance is improved with the addition of new stagingprop parameters. For more information, see stagingprop utility.

Database Cleanup utility enhancements

Data Load utility improves efficiency of loading content

Typically, loading data such as products, prices, and inventory is a significant implementation cost. In previous releases, the mass load utility was the primary tool to load data. The Data Load utility efficiently loads product, price, and inventory data. To load less commonly used data, continue to use the massload utility.

The massload utility is deprecated for WebSphere Commerce Version 7 Feature Pack 6. The Data Load utility is the recommended command-line loading utility. If you are currently using the mass load utility, you are recommended to switch to the Data Load utility to load your CSV and XML input files into your target database. If your system contains scheduled and automated processes that use massload, it is recommended that you update these processes to use the Data Load utility. Other WebSphere Commerce utilities that use the massload utility, such as the acpload utility, continue to use the massload utility in WebSphere Commerce Version 7 Feature Pack 6. If you have business reasons to continue using the massload utility, you can continue to use this utility. For more information about the Data Load utility, see Overview of the Data Load utility. You can switch to the Data Load utility by using the TableObjectMediator to load your data when no business object mediator exists for the data that you are loading. For more about the TableObjectMediator formation, see Data Load utility table-based mediator and builder.

Operations Managers or Site Administrators can now run a file difference process when they run the Data Load utility. By running a file difference, you can improve Data Load utility performance for routine data loads. The use of the file difference preprocessor provides users the ability to load only the changes that exist between frequently loaded files. For more information, see Data Load file difference preprocessing

Marketing caching improvements offer superior performance

The marketing services continue to evaluate what displays in an e-Marketing Spot based on the web activities that are associated with the e-Marketing Spot. The marketing services can be configured to retrieve content to display from the command cache instead of the database. The result of this configuration is superior performance for your customers when they visit your site.

To improve caching for better storefront performance, you can use an e-Marketing Spot JSP caching technique that is based on activity behavior. The marketing engine automatically detects if the e-Marketing Spot is static or dynamic. If the e-Marketing Spot is static (displays the same results for all customers), then JSP caching can be used for the e-Marketing Spot results. If the e-Marketing Spot is dynamic (displays different results for customers), then the marketing engine determines the content to display in the e-Marketing Spot. The marketing engine uses the DynaCache command cache and distributed map cache entries to display the results.

For more information, see Overview of e-Marketing Spot JSP caching based on activity behavior

Reduce risks with Business Object thresholds

For more information, see Business Object thresholds

Improve SQL query performance under workspaces in the Data Service Layer

For more information, see Techniques for improving the performance of SQL queries under workspaces in the Data Service Layer

Staging triggers use database sequence technology to improve performance

Simplified thread management

For more information, see Creating work managers for custom thread groups

Improved performance and functionality with DB2 JCC type 4 connection type

This new connection type provides improved performance and functionality for WebSphere Commerce. This change includes both the run time data source connections and the utilities connections, such as staging utilities, loading utilities, dbclean, and acpload.

stagingprop.sh –dbtype DB2 -sourcedb stagingDBName –destdb productionDBName

stagingprop.sh –dbtype DB2 -sourcedb host:port/stagingDBName –destdb host:port/productionDBName

You can still use the type 2 connection type database name syntax, however, this syntax is converted internally. The type 2 syntax is converted into type 4 syntax and a type 4 database connection is created. This naming conversion is completed with the DB2Administrator class provided by the DB2 JCC driver. To avoid a potential performance impact because of the conversion, use the type 4 connection type database name syntax.

If you choose to use the type 2 connection type database name, ensure that the database is cataloged properly on the local machine. The DB2Adminstrator class requires the DB2 catalog information to convert the host name and port number from the type 2 connection type name syntax.

For more information, see stagingprop utility.

Effective and reliable low-level data caching

Most user and session-related caching can now be removed from the default baseCache servlet cache and moved to data cache object caches, by defining the optional services/cache/WCUserDistributedMapCache and services/cache/WCSessionDistributedMapCache object caches. Doing so can significantly improve the performance of the baseCache, especially if it is configured to use WebSphere eXtreme Scale, where important custom jsp, servlet, and command caching are normally performed. For more information, see WebSphere Commerce data cache.

The new WCDataCache Java class can be used by custom code to take advantage of certain data cache enabled entity access beans. The class can also be used to issue data cache invalidations when custom code modifies certain database content. For more information, see com.ibm.commerce.datatype.WCDataCache.

Low-level instrumentation of entity EJB beans and the WebSphere Commerce data services layer, coupled with database triggers and the DynaCacheInvalidation scheduler job, ensure that entries are removed from the data cache when their content becomes stale because of database updates of the database tables from which the content was derived.

The DynaCacheInvalidation scheduler job provides several new capabilities to help invalidate cached data from several places. These capabilities include custom servlet caches, object caches, and WebSphere Commerce registry objects, in addition to normal data cache object caches and the default baseCache servlet cache. For more information, see DynaCacheInvalidation URL.