Gen Java application DB performance (Window v Cooperative packaging)
search cancel

Gen Java application DB performance (Window v Cooperative packaging)

book

Article ID: 374502

calendar_today

Updated On:

Products

Gen

Issue/Introduction

Gen 8.6 Java Web application with Window packaging running under WebSphere on z/OS gives poor DB2 database performance i.e. application is slow and gives the database contention and table deadlock problems on tables which many users are updating.
After repackaging as Cooperative (Client/Server) the performance seems to be a lot better. Is there any reason for this?

Environment

Gen Java Applications.

Resolution

Background information:

  • With Cooperative Packaging it is building a "THIN" Web Generation Java client and an EJB Server which does the database access.
    With Window Packaging it is building a "FAT" Web Generation Java client which also does the database access and there is no separate client/server concept and no EJB.

  • EJBs manage transactions using Java Transaction API (JTA) which supports two-phased commit when using XA-compliant JDBC and JTA drivers: EJB Server Generation

Recommendations:

  • Gen Engineering don't recall hearing of performance problems with "FAT" clients as long as the "Use JDBC DataSources" option is selected at Assemble time. That option is enabled by default.
    If that option is not selected, then the DriverManager metgod (jdbccfg.properties file) would be used to make the connection to the database.
    The doc. page How to Configure JDBC Access describes the two methods.
    The DataSource method would be more performant than the DriverManager method.

  • For the .ear file Assemble step (EAR File Assembling).
    The WAR tab options related to the database ("Use JDBC DataSources" and "Use JTA transactions") are only really relevant for the Window Packaged application because in the Cooperative version there is no database access via the client.
    The "Enable Threads" option in the "Web Gen Client" tab is deliberately disabled for WebSphere so it is possible to enable "Use JTA transactions" for WebSphere.

  • If "FAT" clients are truly needed, then the advice is to verify that both "Use JDBC DataSources" and "Use JTA transactions" are selected when assembling the application.

  • In general using a Cooperative Packaged Java application is advised because a typical enterprise application would normally be a two-tier or three-tier application. That brings all the benefits that EJBs (Enterprise Java Beans) were designed for i.e. a server-side component with the business logic and a container which has features like better transaction control etc.

Additional Information

See Gen 8.6 doc. page Java Generation and in particular:

  • Java Runtime
    "In the EJB environment, the runtime uses the facilities that are provided by the EJB Container to cache objects such as resource management, transaction control, and flow control."

  • Multiple Database Support
    "Gen Java applications use JDBC and are designed to allow access to one or more databases within a given procedure step. Clients wishing to use this feature must create a database resource for each database to be accessed by the procedure step.
    In contrast, Gen C applications can access only one database for a given procedure step. This is due to the use of the default database handle for all embedded SQL statements.
    Commits and rollbacks for multiple database connections may or may not be performed using a two-phased commit facility. In the Java Web Client environment, two-phased commit is supported only when the deployment options for using JDBC DataSources and JTA transactions are set and properly configured. In the EJB environment, two-phased commit is supported only when utilizing XA-compliant JDBC and JTA drivers."