Data Tier Performance


Data Tier Performance

The data tier within a WebSphere environment relates to all components associated with the database itself or Java components that communicate with the database.

Use WebSphere Data Sources

It's possible to develop your applications without WebSphere configured and managed data sources. To gain the maximum advantage of a centrally managed application environment, however, it's crucial that you use WebSphere data sources (and ultimately WebSphere connection pool managers).

When you use the WebSphere managed components, the application's JVM and containers are centrally aware of the state of all transactions, queries, connections, and threads within the applications' runtime. This ensures that your applications are running in a contiguous environment, rather than an environment that is compartmentalized with differing, nonaware components.

Using these data sources also enables you to support connection pooling and other WebSphere extension-based services, and it lets you monitor the state of all communications and transactions using the PMI and Resource Analyzer/Tivoli Performance viewer interfaces.

Performance and scalability benefit:

1

Implementation complexity:

2

Release JDBC Resources When You've Finished with Them

It's a common problem to find application code in which JDBC resources that were once created and used during an application's database transaction are left open and unused well after the database transaction has been completed. Like any other objects, these JDBC connections, statements, and result objects consume memory. The memory consumption is even more evident if you have large result sets coming back from your database ”those remain in memory after the database query's completion.

Not only does this consume valuable JVM memory, but it also consumes resources from the connection pool managers' list of available free database connections. By not closing these connections off, you place further load onto your database and resources by not freeing up connections for other application threads. It's imperative that your application code closes down its objects, preferably in the following order:

  • Result sets

  • Statements

  • Connections

The problem is somewhat analogous to developers' misconception that JVM will eventually clean up old and unused objects. In this case, it's incorrectly believed that the pool manager will eventually clean up these objects ( especially the connection object); however, this takes time, and if every database query acted in this fashion, you'd quickly run out of database connections in your connection pool. Be sure that your application code also closes down connections and statements in failure situations, after your application receives or throws an exception.

Performance and scalability benefit:

1

Implementation complexity:

2

Use Container-Managed Persistence Only for High-Read Database Access

Container-managed persistence (CMP) is a solid J2EE technology that takes the notion of having your application server manage all your application plumbing for you to another level. CMP allows you to define a schema using deployment descriptors and entity EJBs, and have the EJB container manage all the database queries, transactions, and persistence layer for you. You don't need to develop any SQL calls ”instead, you use CMP methods such as findByPrimaryKey(value) to locate specific database entries.

CMP is a fairly new technology and it's still evolving. Therefore, there are still a number of potential problems with it if it isn't implemented correctly. With the more recent EJB 2.0 specification, CMP has become a lot better than its EJB 1.1 predecessor, but there's still a ways to go before it provides the same level of broad performance as native JDBC.

Because of the nature of CMP and how it functions, it's well suited to application environments that are high-read, low-write. With each change to the database contents, the CMP beans will need to re-obtain the updated table data from the database. Tuning and configuration items can alter this and the CMP behavior. However, for the most part, CMP is best suited for high-read database environments and best avoided for anything write intensive. (Consider DAOs and native JDBC for write- intensive environments.)

Performance and scalability benefit:

2

Implementation complexity:

4

Use Data Access Objects for General Database Access

I discuss the Data Access Object (DAO) design pattern in Chapter 12 in the context of database performance optimization. Essentially , a DAO is based on an object-oriented pattern. The DAO provides a fa §ade for developers to access database data without having to involve themselves in database connection plumbing and the performance aspects of database connectivity.

The DAO still uses WebSphere connection pooling and data sources, but it provides a level of abstraction for developers to communicate with. This helps to ensure that database accesses are managed and robust rather than having multiple forms of database accesses occurring via different class implementations across an application.

The DAO is essentially an intelligent and structured way of accessing a database layer that uses JDBC as the underlying protocol. In a non-CMP/BMP environment in which frequent database accesses occur, a DAO implementation is a sound option for performance with a high degree of robustness.

Performance and scalability benefit:

2

Implementation complexity:

3

Use Prepared SQL Statements Where Possible

If you have SQL statements in your application that are repeatedly called to the database, you may find that the use of prepared statements provides a higher performing approach. Prepared statements work by allowing the database to cache a common SQL statement and subsequent similar queries to the database and it involves only the passing of bound variables . For example, select name from user_table where color = "pink" is the same as select name from user_table where color = "red" except for the variable.

The parsing of a database query is an expensive task for the query processor to perform. The concept behind SQL prepared statements is that only the variables should change and, therefore, subsequent queries made are the same and don't need to go through the database's query parser engine for compilation. This increases performance and greatly reduces overhead.

The prepared statements' capability is supported by the SQL classes within WebSphere ” specifically , the PreparedStatement() method is used instead of the standard Statement() method for building up and parsing in queries to the database.

Performance and scalability benefit:

1

Implementation complexity:

2




Maximizing Performance and Scalability with IBM WebSphere
Maximizing Performance and Scalability with IBM WebSphere
ISBN: 1590591305
EAN: 2147483647
Year: 2003
Pages: 111
Authors: Adam G. Neat

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net