InfoCenter Home >
4: Developing applications >
4.2: Building Web applications >
4.2.4: Accessing data >
4.2.4.2: Obtaining and using database connections

4.2.4.2: Obtaining and using database connections

IBM WebSphere Application Server Version 4.0 provides two options for accessing database connections:

  • Programming directly to the connection pooling model through the JDBC 2.0 Optional Package API
  • Use of the IBM data access beans, which also use connection pooling but give you additional ability to manipulate result sets

WebSphere Application Server versions earlier than 4.0 also supported the connection manager model, which was based on JDBC 1.0. If your Web applications used the connection manager model, you must migrate these in Version 4.0 to use connection pooling.

IBM WebSphere Application Server also provides data access beans, which offer a rich set of features for working with relational database queries and result sets.

For a comprehensive treatment of WebSphere connection pooling and data access, be sure to read the IBM whitepaper to be published on the Web during the summer of 2001.

Tips for data access programming

If your product installation uses Oracle or Sybase for the repository and you try to use DB2 datasources for enterprise beans, the DB2 JDBC provider might fail to load. To fix the problem, your administrator must run the db2profile and usejdbc2 scripts. For details, see the Related information.

For Merant users only: If your bean-managed persistence entity beans are used with SELECT ... FOR UPDATE and an isolation level of READ_COMMITTED, you might lose updates when multiple transactions to a single bean collide. You can avoid collision by using an over-qualified update approach, as follows:

UPDATE Employee SET c1 = new_c1_value, SET c2 = new_c2_value
WHERE  (primaryKey = key_value AND c1 = old_c1_value
AND c2 = old_c2_value)

In this example, old_c1_value and old_c2_value are the values that were read from the database. new_c1_value and new_c2_value are the values to be stored back.

Considerations for DB2/390

Speak with your DB2/390 administrator about setting the RRULOCK parameter to YES. This ensures that SELECT ... FOR UPDATE statements get an update lock rather than a sharable lock. If your database is using sharable locks and you attempt to commit updates later, the database can become deadlocked.

Go to previous article: Accessing data Go to next article: Accessing data with the JDBC 2.0 Optional Package APIs

 

 
Go to previous article: Accessing data Go to next article: Accessing data with the JDBC 2.0 Optional Package APIs