Learning Bits and Bytes

It is common that in a cluster we have to find out which Tomcat instance is used so that we can monitor the log files of that particular server only. When Tomcat is used as the application server, normally load balancing is done using Apache JK connector (mod_jk). JK connector adds name of actual instance to JSESSIONID cookie so that the connector can know how to route the request to the server which created the session. This works only when sticky session is used. When sticky session is not used, name of actual server is not appended to cookie and request is send to a server picked based on the load on each server. In this case, it is very difficult to identify actual Tomcat server. When sticky session is not used, the solution I can think of is to use a filter that will set a cookie with a value that identifies unique name of the Tomcat instance. This filter should have configuration option to disable enable this cookie based on a configuration. Any changes to the configurati...

Using Oracle trace files is the best way to investigate random performance issues. In a real world web application, it is not practical to enable database trace for entire database as it will result in performance degradation and generates huge trace files. Also it is difficult to dig out useful information from a large file. So the most efficient way is to enable trace for particular connections. Web applications use connection pools and there is no guarantee on which connection is used to serve each request. This makes it difficult to turn on trace for a particular connection. Here comes the Oracle client identifier (CLIENT_IDENTIFIER) to rescue. What is client identifier and how to set it?  Client identifier is a token which can be set by the application. This can be reset/changed by the client application. This identifier can be used to uniquely identify users associated with a connection. I suggest every serious application to set this identifier as this will come handy s...

We have batch process running on Solaris servers. We have been using this for several months and one day we started getting JDBC Protocol violation exception from these jobs. This errors happens after several successful database operations and each time it occurs with a different operation. Fix is to use 64 bit VM. To use 64 bit VM pass argument -d64 as command line parameter to Java. We are using Oracle 11g R3, Solaris 5.10 and JDK 1.6.0_21-b06. java -d64 test.Main This is the stack trace. java.sql.SQLException: Protocol violation ----------- ----------- Caused by: java.sql.SQLException: Protocol violation         at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:459)         at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)         at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:523)         at oracle.jdbc.driver.T4...

It is usual that any production application will have performance issues and it could be due to a slow performing query. As a first step in resolving the issue, we regenerate stats on the tables which are used in the functionality. Beginning Oracle 9i, use the following syntax to generate statistics. begin DBMS_STATS.gather_table_stats('SCOTT', 'EMP', estimate_percent => 30, cascade => TRUE); END; I put this in an anonymous PL/SQL block otherwise it gives error ORA-00900: invalid SQL statement This uses dbms_stats procedure and it replaces ANALYZE TABLE used in Oracle 8i and before. As per Oracle from version 9i onwards ANALYZE TABLE is deprecated and should not be used. What it does is regenerating stats on the table EMP on schema SCOTT. The option estimate_percent says that collect stats by using 30 percent of records. Option cascade tells to generate stats on any dependent tables and indexes. Note that by default Oracle runs nightly jobs to g...