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

Problem explanation

By examining the alerts, 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.

We can now use the model to map the problem to the source level. By selecting the JMS session we can examine the point at which it was created (source creation points are available for application-level entities). Figure 6 shows an example of this.

Figure 6
Figure 6: Show instantiation location for the JMS Session (click the image for a full-size screen shot)

Figure 7 displays the source that shows it has been created with the transaction attribute set to true.

Figure 7
Figure 7: JMS Session creation source line

If we wish 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. Because the JMS session-specified transaction was unintended, no code is 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 had not been made 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 have 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 
       == JMSSession and
exists( select Transaction t1 from Transactions
        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 creator of the original transaction and the creator of the problematic session.

JDBC Connection Not Closed alert

If we continue, a further alert appears, as shown in Figure 8.

Figure 8
Figure 8: A "JDBC connection not closed" alert (click the image for a full-size screen shot)

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.


The Server View, shown in Figure 9, illustrates the direct access from the servlet to the DataSource (itself a doubtful practice that could be checked).

Figure 9
Figure 9: The Server View of the JDBC connection alert (click the image for a full-size screen shot)

Connection Not Closed model alert query

This alert requires a model trigger to dynamically create a second trigger which 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) // the frame the connection is passed back to for use 
when t1 
connection.attribute('closed') == false)

Note that this rule is aimed at detecting an unsafe pattern of use: If we wished only 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 is not just less wasteful but more maintainable.


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


We have 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 serious structural problems which were not exhibiting any obvious effect and would not be obvious from source code or from tracing application components.

eoSense can use DMA to visually represent almost all Java EE services and can monitor these independently or in combination. It can detect automatically a wide range of serious construction defects, with more detectors being added as new problem patterns are defined. It is 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.


  • The eoSense page on the eoLogic Web site
  • Read other architect articles in Arch2Arch

Alan West is CTO of eoLogic, responsible for all product development. He was previously a founder of Object Software Technology Ltd, and has over 20 years experience in software tool design and architecting large software systems.

Gordon Cruickshank is co-founder of eoLogic, a software tools company created to develop innovative testing and debugging solutions. He was previously development manager at Wind River Systems and Objective Software Technology, developing C++ visualization and debugging tools.