WebLogic Server–Use the Execution Context ID in Applications–Lessons From Hansel and Gretel
- by james.bayer
I learned a neat trick this week. Don’t let your breadcrumbs go to waste like Hansel and Gretel did! Keep track of the code path, logs and errors for each request as they flow through the system. Earlier this week an OTN forum post in the WLS – General category by Oracle Ace John Stegeman asked a question how to retrieve the Execution Context ID so that it could be used on an error page that a user could provide to a help desk or use to check with application administrators so they could look up what went wrong. What is the Execution Context ID (ECID)? Fusion Middleware injects an ECID as a request enters the system and it says with the request as it flows from Oracle HTTP Server to Oracle Web Cache to multiple WebLogic Servers to the Oracle Database. It’s a way to uniquely identify a request across tiers. According to the documentation it’s:
The value of the ECID is a unique identifier that can be used to correlate individual events as being part of the same request execution flow. For example, events that are identified as being related to a particular request typically have the same ECID value. The format of the ECID string itself is determined by an internal mechanism that is subject to change; therefore, you should not have or place any dependencies on that format.
The novel idea that I see John had was to extend this concept beyond the diagnostic information that is captured by Fusion Middleware. Why not also use this identifier in your logs and errors so you can correlate even more information together! Your logging might already identify the user, so why not identify the request so you filter down even more. All you need to do inside of WebLogic Server to get ahold of this information is invoke DiagnosticConextHelper:
weblogic.diagnostics.context.DiagnosticContextHelper.getContextId()
This class has other helpful methods to see other values tracked by the diagnostics framework too. This way I can see even more detail and get information across tiers.
In performance profiling, this can be very handy to track down where time is being spent in code. I’ve blogged and made videos about this before. JRockit Flight Recorder can use the WLDF Diagnostic Volume in WLS 10.3.3+ to automatically capture and correlate lots of helpful information for each request without installing any special agents and with the out-of-the-box JRockit and WLS settings! You can see here how information is displayed in JRockit Flight Recorder about a single request as it calls a Servlet, which calls an EJB, which gets a DB connection, which starts a transaction, etc. You can get timings around everything and even see the SQL that is used.
http://download.oracle.com/docs/cd/E21764_01/web.1111/e13714/using_flightrecorder.htm#WLDFC480
Recent versions of the WLS console also are able to visualize this data too, so it works with other JVMs besides JRockit when you turn on WLDF instrumentation.
I wrote a little sample application that verified to myself that the ECID did actually cross JVM boundaries. I invoked a Servlet in one JVM, which acted as an EJB client to Stateless Session Bean running in another JVM. Each call returned the same ECID. You need to turn on WLDF Instrumentation for this to work otherwise the framework returns null. I’m glad John put me on to this API as I have some interesting ideas on how to correlate some information together.
