|
YOUR FEEDBACK
Did you read today's front page stories & breaking news?
SYS-CON.TV |
TOP THREE LINKS YOU MUST CLICK ON Application Server IBM WebSphere Application Server - WAS for z/OS and DB2
Clearing up some of the conceptual confusion
By: Linfeng Yu
Oct. 12, 2005 05:15 PM
However, you should be aware of a restriction if you plan to use LTC with DB2. The RMLTs in an LTC don't commit until the transaction boundary defined in LTC is reached. Be careful about lock duration. And if you manipulate the same table using different database connections other than serially reusing the same connection, you can be exposed to database deadlocks (under certain database isolation levels).
Sharing Database Connections To share database connections, certain conditions have to be met. In WAS for z/OS you can only share a connection scope in a global transaction. However you can serially reuse connections in an LTC. The application's deployment descriptor element Sharing scope has to be set to shareable as shown in Figure 7. The following database connection properties have to be the same:
If the resource reference of the Data Source is marked Unshareable, the Connection handles aConn and bConn will have different physical connections. The application can fail if the Data Source doesn't support two-phase commit. Even if the Data Source has two-phase commit support, a deadlock is possible. Using shared connection can avoid this problem because of a strategy that calls for multiple work items to be performed on the same connection. The use of shareable connections in WAS for z/OS is recommended. However you can still use unshareable connections if your application has to change connection properties. The get/use/close pattern is preferred to share connections. Should you need more information about sharing connections, please refer to the resource. It's worth pointing out that WAS for z/OS connection manager doesn't reset database connections returned back to the connection pool. The connection returned by the getConnection call will carry the properties set by the application component before it's returned back to the connection pool. For example, a connection is returned back to the connection pool with AutoCommit value FALSE. If the connection is acquired from the connection pool again, the AutoCommit value of the connection is still FALSE rather than TRUE. Initializing the connection before using it can avoid undesired behavior.
Locking and Isolation Level There are four isolation levels in DB2 for z/OS: Repeatable Read (RR), Read Stability (RS), Cursor Stability (CS), and Uncommitted Read (UR). Table 2 shows the DB2 for z/OS and JDBC/SQLJ isolation mapping. The isolation levels in a Java application are determined by the following precedence order:
In two-phase commit processing, if the other resources in the transaction don't maintain locks, such as WebSphere MQ, the application should exploit DB2 for z/OS as the last resource enlisted in the transaction to reduce the lock duration.
Conclusion
Resources
YOUR FEEDBACK
WEBSPHERE LATEST STORIES . . .
SUBSCRIBE TO THE WORLD'S MOST POWERFUL NEWSLETTERS SUBSCRIBE TO OUR RSS FEEDS & GET YOUR SYS-CON NEWS LIVE!
|
SYS-CON FEATURED WHITEPAPERS MOST READ THIS WEEK BREAKING WEBSPHERE NEWS
|
|||||||||||||||||||||||||||||