By examining the alerts, model entities, and relationships we can identify the elements of the problem:
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 7 displays the source that shows it has been created with the transaction attribute set to true.
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.
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 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 creator of the original transaction and the creator of the problematic session.
If we continue, a further alert appears, as shown in Figure 8.
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).
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.
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.