Considerations Prior to JDBC Virtualization

Products

• CA Continuous Application Insight (PathFinder)
• Service Virtualization

Issue/Introduction

JDBC Virtualization can be very powerful. However, there are several areas that must be considered prior to recording transactions.

Prerequisite: The DevTest agent must be installed prior to capturing JDBC transactions. If you need assistance installing the DevTest agent, please open a support ticket.

JDBC Virtualization is not meant to be a database replacement. It is intended to virtualize a small number of calls on a relatively static database.

Warnings from the DevTest Documentation:

•  JDBC is a chatty protocol. For example, a few clicks in a user interface that retrieves data from a database can result in a huge number of JDBC API calls. This behavior can make it difficult to model properly. If you want to capture and virtualize JDBC database traffic, consider doing so at a higher layer.
• This feature is supported in this release, though we do not encourage users to use the feature without direct guidance from a CA professional. A CA professional can help evaluate your specific use case and determine the best method to virtualize.

Environment

All supported DevTest platforms.

Resolution

Specific items to consider before capturing JDBC transactions:

1. Supported databases and drivers:
   Because JDBC is very chatty, only specific database and driver versions are supported. See the documentation for your specific DevTest version.
2. Size of ResultSet:
   The way a program processes a ResultSet is very different from the way the agent processes it.
   • Program: Receives a cursor (pointer) to the ResultSet. The program usually processes the ResultSet one row at a time using ResultSet.next().
     Memory and CPU requirements are limited to processing one row of data.
   • Agent: The agent must capture the entire ResultSet as an object, not just one row. The object is then serialized and sent to the Broker for further processing.
     Memory: Contains two complete copies of the ResultSet; one for the original object and one for the serialized object. Can result in Out Of Memory errors or Garbage Collection thrashing.
     CPU: Must process the entire ResultSet and then serialize it. Can result in CPU thrashing, connection timeouts and other errors.
3. Types of database calls:
   JDBC Virtualization is intended for calls that return a ResultSet and may have problems processing other types of calls.
   Select statements: Usually only limited by size (see above).
   Insert and Delete: Usually processed correctly but excessive inserts and deletes can cause issues.
   Rollback, etc…: These commands can affect several tables and should not be virtualized.
4. JDBC Virtualization is not a database replacement:
   A database is a complicated program. Virtualizing JDBC calls captures the ResultSets that were returned during recording. For these reasons, you cannot expect the virtualized transactions to act like the database.
   Banking Example: If you have a starting balance of $500 and deposit $100, the database and program know the balance is $600. All the virtualized transactions know, is an input of $100 resulted in a return value of $600. It does not know how that value was calculated. Using the virtualized transactions with a starting balance of $500; depositing $200 will not result in $700 being returned.
5. VSE
   When a JDBC Virtual Service is deployed, the VSE notifies the agent(s) of the deployment. However, there are several limitations:
• Only one Virtual Service can be active at one time. If multiple JDBC Virtual Services are deployed, the agent only knows about the last deployment.
• All the database transactions for a given agent and database url combination must be virtualized in one vsi file. If there are any missing transactions, they will result in a “No Match Found” error.
• All JDBC transactions the agent sees, will be sent to the VSE; regardless of database connection url. Any calls to a different database connection url will result in a “No Match Found” error.
• An agent extension can modify some above behavior but support cannot assist in writing or debugging the extension. Please contact CA Professional Services for assistance.
6. JDBC transactions are recorded as a conversation.
   In most cases, the order the transactions are recorded must be the same order used during playback.
   There is not an option to record stateless JDBC transactions

Alternatives to JDBC Virtualization:
Decide exactly what you are trying to test. Are you testing the class making the JDBC calls? Are you testing something else?

1. Virtualize at a higher layer:
   If you are not testing the class making the JDBC calls, you can usually move up the stack. This means virtualizing at least one or two classes before the JDBC calls.
2. Test Data Manager (TDM):
   If you need to virtualize the JDBC calls and JDBC Virtualization does not meet your needs, TDM may solve your issues. TDM offers an automated solution to one of the most time-consuming and resource-intensive problems in Continuous Delivery—the creating, maintaining and provisioning of the test data needed to rigorously test evolving applications. CA Test Data Manager uniquely combines elements of data subsetting, masking and synthetic, on-demand data generation to enable testing teams to meet the agile needs of the organization.