Derived Model Analysis: Detecting J2EE Problems Before They Happen
Pages: 1, 2, 3

DMA Example

To look at how the abstraction mechanisms of DMA allow construction problems to be detected and explained let's look at it operating on a sample application. We will aim to show how we can identify a pattern of application and framework components that indicates a problem. We will then show how the problem can be visualized and explained back to the source level by exploring the model at the point of detection.

Example application

Figure 2 shows a simple Web-based order processing example that accepts orders and processes them in the following manner:

• An order invoice is created and queued using JMS to an existing invoice service to create and process the invoice.
• The order details are queued using JMS to an order processing system to separately process and deliver the order.

Figure 2: Example order form

However there is a problem: The invoices do not arrive at the invoice processing application although the order entries are processed correctly.

Monitoring the application

To monitor the sample application we will run the BEA WebLogic Server from our DMA analyzer, called eoSense, which consists of a server agent and a client. The agent constructs and checks the abstract model as WebLogic Server executes. When a problem is detected, the agent signals an alert to the client.

Transaction-related alerts

Running the example application results in the initial alerts being detected (after several less serious alerts), as shown in Figure 3.

Figure 3: Sample alerts

Looking at the alerts in more detail:

• A JMS message sent inside a JTA transaction using a non-XA Connection - A JMS connection created from a non-XA factory was used to create a JMS session and sender. The sender was then used with the context of a JTA transaction. This may indicate an XA JMS connection should have been used instead.
• Mixed transactions - The JMS sender has been used from a JMS session marked as transacted, but a JTA transaction is already active on the current thread.

DMA visualization

When the Mixed Transaction alert is recorded a diagram of the ERA model allows the context of the problem to be understood. In eoSense this is called the Server View, and an image of the Server View is shown in Figure 4.

Figure 4: Entities and relationships in the server view for the mixed transactions alert (click the image for a full-size screen shot)

We can see there are two active transactions, one linked to the Order Processing servlet and the other linked to a JMS session. We can also see that the Order Processing servlet has communicated with two JMS Senders. Figure 5 shows diagrammatically the named key entities and relationships from Figure 4.

Figure 5: Diagram of entities and relationships at the mixed transactions alert (click the image for a full-size screen shot)

• Two in-flight transactions are held by the Transaction Manager
• An "Initiated By" relationship exists between the OrderProcessingExample servlet and Transaction 1.
• An "Initiated By" relationship exists between the JMS Session 1 and Transaction 2.
• The OrderProcessingExample servlet has sent two Messages: a "Has_Called" relationship to JMS Sender 1, which is attached to the Order JMS Destination, and a "Has_Called" Relationship to JMS Sender 2, which is attached to the Invoice JMS Destination.

Note: This example is not an endorsement of initiating JTA transactions in servlets. That's another doubtful practice, and one that eoSense can also detect, but it's simpler to show the example this way.