Maintaining POJO transactions in the perfino VM group configurations is an extra step in the development workflow and can get easily out of sync with the actual code. While POJO transactions are ideally suited for external classes, it is much more maintainable to directly annotate the methods and classes of interest in your own code.

The naming of this transaction type comes from the DevOps software development method that stresses the importance of increased collaboration between the development and the operations departments. Thinking about and implementing monitoring aspects at development time falls into this category.

The perfino annotations are located in the JAR file api/perfino_api.jar, see the javadoc overview for how to download this JAR file with Maven, Ivy or Gradle.

All annotations have a class retention policy. This means that they are present in the class file, but the JVM does not load them into memory. Code that queries runtime annotations on a particular method cannot be confused by the additional perfino annotations because they are only detected by perfino at the class loading stage and do not appear in the loaded class objects.

The usage of DevOps transactions is described in detail in the Javadoc that is present in the api/doc directory of the perfino installation.

Policies

DevOps annotations only define the transaction naming, but not the policies for transactions. Policies are closer to the operation side and often need to be adjusted in production.

It is possible to select different DevOps annotations in the perfino configuration by way of the group name. Each DevOps annotation can have a "group" parameter that is set to the empty string by default.

If the configured groups are not granular enough or if you want to single out a particular class, go to the next step to add a class filter. Here, it is also possible to discard all DevOps transactions that originate from the selected group and classes.

On the last step of the wizard, you define the policies for the selected DevOps transactions. As with other transaction types, it often makes sense to keep a catch-all transaction definition at the bottom and add more specific transaction definitions at the top.