Thursday, October 25, 2007

Integrating JAMon war with your application on Websphere

We were using the JAMon package for performance monitoring. We needed to integrate the JAMon WAR file contents into our application so that we could get the web-pages used for monitoring the application.

On Websphere 6.1, the class-loader hierarchy and our security policies did not allow for JAMon libs to be added at the system class-loader level.
One option was to include the contents of the JAMon war file into our WAR file.

But I thought a cleaner option would be to make a EAR file with 2 web-modules (one war of my application and other jamon.war)
On WAS 6.1, I changed the class-loader policy of the application to: Single class loader for application.

The application.xml file for the EAR file contained the following items:

<application id="Application_ID">
<display-name>MyApplication.ear</display-name>
<module>
<web>
<web-uri>MyApplication.war</web-uri>
<context-root>MyApplication</context-root>
</web>
</module>

<module>
<web>
<web-uri>jamon.war</web-uri>
<context-root>jamon</context-root>
</web>
</module>
</application>

Wednesday, October 24, 2007

Access predicates and Filter predicates in Explain plan

In Oracle 10g, when we see the explain plan for a SQL, then there are 2 new items that are of interest - the 'Access predicate' and the 'Filter predicate'.
We know that depending on the predicate information ('where clause') the Oracle optimizer chooses the optimal path for executing the query.

So the 'access predicate' information tells us how the Oracle optimiser is accessing the rows of the table - i.e. if the optimizer is using an index, then what predicate made it use the same.

The 'filter predicate' tells us what criteria Oracle is using to filter rows from the returned rowset (the rowset was fetched based on the 'access predicate') .

Tuesday, October 09, 2007

Webpshere v6.1 deployment hack

Whenever I wanted to change a single file on WAS server, I often used to copy that file to the 'installedApps' EAR directory of the application.

This used to work and though not mentioned in any IBM redbook; was considered as a hack by our team. But one day we ran into a problem which took us ages to decipher.

Whenever we changed the web.xml in WEB-INF, the changes were never reflected. For e.g. if we added a new struts-config entry to web.xml or a new filter, the configuration was never picked up.
We never really noticed this and thought the problem was with our struts-config file.
But the core issue was that WAS always picks up the web.xml file of an application from a different directory

-/opt/IBM/WebSphere/AppServer/profiles/
{profileName}/config/cells/{CellName}/applications/
{Application_EAR}/deployments/{Application_WAR}/WEB-INF
I changed the web.xml file here and all issues with struts-config were solved :)

JAMon JDBCMonProxy -getting the orginal connection

While using JAMon to monitor SQL perf stats, we faced a small problem - at one place we needed the underlying OracleConnection object and not the proxy, as we were calling a vendor-specific method on it.
Thankfully the JAMon API MonProxy object has a "getMonitoredObject()" method through which I could get hold of the OracleConnection object and use it.

Here is the sample code snippet: (just in case someone else needs it :)

// we need to do this as the 'setEndToEndMetrics'
// method is only available on an OracleConnection.
if (Proxy.isProxyClass(connection.getClass()))// if a dynamic proxy object
{
InvocationHandler invocationHandler =
Proxy.getInvocationHandler(connection);
Object monitoredObject =
(MonProxy) invocationHandler).getMonitoredObject();
((OracleConnection) monitoredObject).
setEndToEndMetrics(metrics, (short) 0);
}