Product overview > What's new summary > New features and functionality > What's new for administrators
Performance enhancements
Reduce risks with Business Object thresholds
Applying limits on business operations reduces the risk of system attacks where unbound conditions might result in system failures.
Improve SQL query performance under workspaces in the Data Service Layer
SQL queries under workspaces can suffer performance issues. Performance degradation often occurs if the database is not being properly maintained or if queries can be rewritten more efficiently. In addition to making sure that the database is properly maintained, there are several techniques that can help improve the performance of SQL queries under workspaces. While no single technique yields significant results, a combination of several techniques can help achieve considerable performance improvements in many applications.
Marketing caching improvements offer superior performance
The Management Center marketing component now provides a caching method that improves the performance of e-Marketing Spots on the store pages. The method uses command caching to reduce redundant database queries.
The marketing services will continue to evaluate what to display in an e-Marketing Spot according to Web activities; however, the marketing services can now be configured to retrieve the data to display from the command cache instead of the database. The result is superior performance for the customers as they shop on the site.
To further improve performance, you can take advantage of these additional caches provided with v7:
- A JSP cache for e-Marketing Spot snippets
- A Distributed Map cache for marketing data
Data load utility improves efficiency of loading content
The new data load infrastructure provides an efficient load solution through a single utility and service for reading data from a source file or repository, transforming the source data to WebSphere Commerce format, allocating and resolving WebSphere Commerce identifiers to data, and loading the data into the database.
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 mass load utilities.
Stage triggers use database sequence technology to improve performance
All staging triggers have been updated in v7 to use database sequence technology to generate the primary key values for the STAGLOG table. The new triggers improve the performance and scalability of the staging server, and address concurrency issues experienced with the previous implementation of staging triggers.
Simplified thread management
The work manager is used in WebSphere Commerce v7 for WebSphere Commerce Scheduler, MQ Listener and other components, instead of spawning Java threads. By leveraging the work manager, administrators use a consistent interface to manage these additional asynchronous processes, while WebSphere Application Server now manages these additional processes that are part of a J2EE application.
Improved performance and functionality with DB2 JCC type 4 connection type
In WebSphere Commerce v6, WebSphere Commerce used the DB2 legacy type 2 connection type. In WebSphere Commerce v7, WebSphere Commerce has upgraded to the 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, massload utilities, dbclean, and acpload.
The type 2 connection type database name syntax has been deprecated for most utility command interfaces in WebSphere Commerce v7. For example, the syntax of the following database names in the sourcedb and destdb parameters are deprecated:
stagingprop.sh –dbtype DB2 - sourcedb stagingDBName –destdb productionDBName
Instead, use the following type 4 connection type database name syntax:
stagingprop.sh –dbtype DB2 - sourcedb host:port/stagingDBName –destdb host:port/productionDBName
Although you can still use the type 2 connection type database name syntax, this syntax is converted internally to type 4 syntax and a type 4 database connection is created. This naming conversion is completed using the DB2Administrator class provided by the DB2 JCC driver.
To avoid a potential performance impact due to the conversion, it is recommended that you 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.
Related concepts
Business Object thresholds
Overview of the data load utility
Stage server
Scheduler configuration parameters
Scheduler
Performance
Related tasks
Improve marketing performance using caching
Reuse custom staging triggers
Related reference
Techniques for improving the performance of SQL queries under workspaces in the Data Service Layer