Firefox 1.5 Upgrade – Watch out!

I have a great respect for Mozilla applications after having successfully making our company’s product “Firefox compliant“. Our experience revealed that, IE is very leniant and hence does not scream if we write non standard html/javascript codes. However, all we had to ensure is to make the codes standard compliant, then it automatically worked both in Firefox as well as IE.

With the same confidence, I upgraded my Firefox to the latest and great v1.5. Guess what, lots of application’s functions started to misbehave. One main issue is that we often get “Script is taking long time to complete and is not responding. Do you want to stop or continue the script?

After lots of trial and error, I tried a hack which worked for me…

Basically, in the script function, I am setting the window.status to some value with the assumption that the browser should not scream as long as there is some update happening in the screen. Guess what? this hack worked!!!

Well, the happiness was very shortlived when I found that there is an option in Firefox called “change the status bar text” under “Advanced Javascript settings” and to add to my depression, the option is by default UNCHECKED.

Therefore, though I have a hack, the user has to change this setting for my application to work fine in Firefox 1.5.

Hope someone finds a permanent solution to this issue, or is it a Firefox issue, that one day Firefox will fix it!


Advertisements

JDBC Transaction Control behavior varies when using Pooled and Non Pooled Connections

Before going into details let us observe the below code

try {
conn = getDBConnection();
conn.setAutoCommit(false);
PreparedStatement ps =
conn.prepareStatement(Some Update Sql 1);
ps.executeUpdate(Some Update Sql 1);
conn.commit();
ps.executeUpdate(Some Update Sql 2);
} finally {
try {
if (conn != null) conn.close();
} catch (SQLException ex) {
Debug.logError(ex, "Some Error Message");
}
}

What will happen to the second sql updation …? Will it get committed or rolled back? There are two flavours of answer to this…

  1. When connections are not pooled
    In this case, Connection.close() method commits all the uncommitted statements (As per 9i Oracle JDBC Driver).
  2. When connections are pooled
    In this case, Connection.close() really does not close the connection but releases it to the connection pool for reuse by somebody else. In this case, situation is bit undeterministic. The outcome purely depends on how the Pool manager manages. We found in Weblogic pool management, Connection.close() results in all open cursor closure and resetting of AutoCommit flag. But the uncommitted transactions are neither committed nor rolledback. All the exlusive locks obtained for the previous updation will remain alive. This behavior continues until the same connection from the pool is assigned for somebody else and he either commits or rolled back.

Now, Consider the below piece of code,

PreparedSQLRunner ps = null;
try {
conn = getDBConnection();
conn.setAutoCommit(false);
PreparedSQLRunner.executeUpdate(Some Update Sql 1);
conn.setAutoCommit(true);
ps = new PreparedSQLRunner();
ResultSet rs = ps.executeQuery(Some Select Sql);
....
} finally {
try {
if (ps != null) ps.close();
} catch (SQLException ex) {
Debug.logError(ex, " ");
}
try {
if (conn != null) conn.close();
} catch (SQLException ex) {
Debug.logError(ex, " ");
}
}

In the above context, what would happen to the uncommitted update sql ?

As per JDBC API specification, when we change the Auto Commit flag of a Connection object from false to true, the next immediate statement on that connection, will commits all its previous uncommitted operations (that were happened with Auto Commit Flag set false). So, the call to executeQuery method, results in the committing of the previous uncommitted updation in addition to its expected service.

Wondering where does Windows Service pick the Locale Settings from?

Boy! couple of months back I had encountered an issue where my application which is running as Windows NT Service, always used the Locale settings thats entirely different from what is set in the control panel by the logged in user.

I thought if I had provided an User Account to be used as the credentials for the service, then the windows service might use that particular user’s locale settings. But Hard Luck!

Later on further weaving thru the Windows Registry, realized that windows captures the Locale Settings that I had provided during the initial Installation of the WinXP Operating System.

This basically means Windows maintains TWO Locale information, one about the logged in user and the other which is the default that was provided during Windows Installation.

The following Registry Key stores Current Users Locale Configuration
HKEY_CURRENT_USER\Control Panel\International

The following Registry Key stores the Default Users Locale Configuration
HKEY_USERS\.DEFAULT\Control Panel\International

Tough Find !!!

Oracle 10g Thin Driver setFetchSize() can corrupt Data

Recently, we had our application database upgraded from Oracle 9i to Oracle 10g. And therefore we also upgraded oracle jdbc thin driver accordingly.

We were surprised by a nice “ArrayIndexOutOfBoundsException” when reading data from the ResultSet.

After lots of research, I learnt about an inherent bug in Oracle 10g thin driver where if we set the fetchSize on the PreparedStatement we have to set the same fetchSize on the ResultSet as well. This certainly was not the case with previous versions of Oracle.

To my knowledge this bug is not fixed yet. The workaround until then is to set the FetchSize on the ResultSet object whenever you set the FetchSize on the PreparedStatement.

Code snippet:

PreparedStatement ps = conn.prepareStatement(“Select * from some_table”);
ps.setFetchSize(20);
ResultSet rs = rs.executeQuery();
//rs.setFetchSize(20); //Uncomment this line to reproduce the issue.
while (rs.next()) {
// … process the row
}

A very useful HTTP(S) Sniffer Tool

Recently, I was stuck with an issue that I badly wanted to sniff the SSL Packets received from my web application. Thanks to the ClearWatch tool.

The tool from Covelight allows you to sniff HTTP packets encrypted with SSL as well. All you need is to have the Private Key of the Server.

The tool is available for download from http://www.covelight.com/downloads.php