Consider following trivial JavaEE application:
We want to test FooBean. However FooBean uses database or a distributed cache (e.g. Infinispan) or even another EJB bean. I.e. it depends on expensive component.
execution goes straight without locking anything in database. Execution may fail if a concurrent thread modified the same record ( OptimisticLockingException will be throw in this case)
database-level locks are acquired and hence deadlock may occur
|Transaction Span||Temporal and spatial span
entity version could be conveyed to client which can hold it as long as he wants. This allow a virtual transaction to span both temporal and spatial. Only during commit version check will be enrolled to ensure data integrity
it would be a suicide to hold a database-level lock on an entity which is edited by client remotely. This would quickly exhaust all system resources. As such no transaction span is available
changes made to an entity in another thread are detected and transaction is aborted – this prevents unwanted overwrites
changes made to an entity in another thread are not detected – they are simply overwritten (last change wins)
|Changes in Tables||Required
need to add column into each table for storing a version counter ( javax.persistence.Version)
everything needed is provided by database itself
doesn’t require and database interactions – recommended for web apps which must scale
requires explicit locking in database which is expensive
Let’s consider a JavaEE web application with an API exposed via RESTful endpoints. Exceptions… They are just everywhere and of course they will be raised in our API as well. As such during development of API following challenges will emerge:
|1||Dynamic instrumentation||Now it’s possible to inject tracing into a running Java process without any restarts! One can repeat this many times for different classes and methods. After one is finished with experiments all instrumentation traces can be removed leaving application in an original state.
To ease metracer.jar launching a frontend script – metracer.sh – was introduced. One only needs this single script (without any additional bits) to start working! There are a built-in usage notice and help message for a quick on-boarding.
Such dynamic instrumentation was made possible by the use of Java Attach API and JMX technologies
|2||No more promiscuous patching of ClassLoader||Such patching was introduced as an aid against isolation imposed by JavaEE app servers (e.g. WildFly).
It was found another more elegant way to workaround this based on the fact that metracer bits are loaded into a system ClassLoader (see here). Given this one could easily resolve reference to a com.develorium.metracer.Runtime class from any point of program via code:
By using the code snippet above one doesn’t need anymore to patch any class loaders!
|3||Improved stability of instrumentation||Several design flaws and bugs in an instrumentation code were identified and fixed which lead to
With these changes metracer is now a fully functional developer tool ready for hard use in production! Enjoy the POWER of METRACER!
Stack Map Frames in Java is a contradictory addition to the language: they speed up class loading but the same time make big troubles for a code instrumentation tools. During adoption of an ASM framework to a metracer I have stumbled with following main two issues:
Main target audience of a metracer are meant to be enterprise Java applications – metracer must enhance logging of such applications. As such I’ve tried to adopt metracer to a production level Java EE application which runs under WildFly AS. Speaking in terms of RPG games – tons of experience was earned :-). Results of my experiments are below.