Problem Explanation
By examining the alerts, and model entities and relationships, we can identify the elements of the problem:

• There are two transactions, not one as expected
• One transaction was initiated by the servlet; the other by the JMS session. The second transaction is unexpected.

The displayed source in Figure 7 shows that it's been created with the transaction attribute set to true:

If we want both the order and invoice JMS messages to form part of the same overriding JTA transaction, the transaction attribute (the first argument) should be false. And because the JMS Session-specified transaction was unintended there's no code present in the application to commit it (as the presence of the transaction in the eoSense view after order entry processing confirms). And even if the gross error of not committing the JMS-initiated transaction hadn't happened we would still have code that incorrectly creates two transactions, with the possibility of intermittent damaging inconsistencies.

Mixed Transactions Model Alert Query
The DMA model consists of the dynamic set of abstract entities and their relationships, a small part of which we've already examined. But what model trigger fired to signal the Mixed Transactions alert? eoSense defines query triggers as plug-in script inserts to its database, but the trigger can be expressed concisely as:

when relation Transaction_InitiatedBy created and relation.to.type == JMSSession and
exists( select Transaction t1 from Transactions
where relation.from.attribute.thread == t1.attribute.thread)

Having identified the key transaction and session entities, we can then navigate to related entities to show the full set of entities and relationships in the scope of the problem and relate these back to source-level statements. In the example, these are the creators of the original transaction and the problematic session.

JDBC Connection Not Closed Alert
If we continue, Figure 8 shows the next alert that appears.

This alert indicates that a JDBC Connection has not been closed before the methods using it have returned indicating inefficient use. The problem connection is indicated, with captured stacks showing its use without closure, mapping the problem back to the source code.

Visualization
The image of the Server View in Figure 9 shows the direct access from the servlet to the DataSource (itself a doubtful practice which could be checked).

Connection not Closed Model Alert Query
This alert requires a model trigger to dynamically create a second trigger that then fires to indicate the problem:

when relation DataSource_Returned_Connection created
create Trigger(return,single) t1 on findFrame(method.returns(java.sql.Connection) == false)
when t1
connection.attribute('closed') == false)

Note that this rule is aimed at detecting an unsafe pattern of use. If we just wanted to detect connection leaks we could track references but the intention in DMA checking is to highlight unsafe program construction patterns (as well as obviously faulty ones) and so achieve code that's not just less wasteful, but more maintainable.

Efficiency
Doesn't visualization and modeling of this kind impose far too heavy a performance penalty? Well, no. The model is derived from efficient, highly constrained monitoring in the application server, the extent of which is dynamically controlled. The frequency of client updates for visualization can be set to any desired level, and the model can be examined only in retrospect, if that is preferred.

Summary
We've seen an example of Derived Model Analysis in action, deriving an entity-relationship model dynamically from an executing Java EE application, and using this to detect and, importantly, explain clearly serious structural problems that were not exhibiting any obvious effect and would not be obvious from the source code or from tracing application components.

eoSense can use DMA to represent visually almost all Java EE services and can monitor these independently or in combination. It can automatically detect a wide range of serious construction defects, with more detectors being added as new problem patterns are defined. It's clear that, as applications become increasingly based on standardized frameworks, automatically identifying design-level models from application execution and using those models to validate the applications becomes a real and powerful possibility.