Monday, March 24, 2008

Refresh double submit problem

After a HTTP post request, if the user click 'refresh', it may resubmit the form and cause problem.

Redirect the form submit action after complete is a good solution. It changes the 'history'. Ff the user tries to refresh the page, only the result view page is refreshed without form being resubmit.

Wednesday, March 5, 2008

A ridicious RMI issue

The stub files are stored in RMIRegistry. The object is bound when server side publish it via Naming.bind(name, remoteObject). The client side can look up it via Naming.lookup(name) to acquire the network aware stub file.

Basically the remote object is bound to localhost, and inside the stub files, it need the IP address to connect to. It maybe a problem for the host with multiple IPs. It appears that RMI will randomly set an interface IP to be used in stub files.

It causes a ridicious result in my testing. I have a MU (wireless network adapter) connected to the host. And it is miserably used as licence agent (remote object)'s IP in its stub file and crash the system.

Tuesday, March 4, 2008

concurrency general strategy


synchronized(this){
  Connection con = connectionMap.getByIp(ip);
  if (con == null) {
     con = new ConnectionFactory.createConn(..);
     connectionMap.put(con);
  }
  try {
    con.connect() // long-lasting job
  } catch (Exception e) {
     connectionMap.remove(con);
  }
}

Is there a strategy that we can apply to remove connect() out of the synchronized block for performance consideration?

The solution is to split one big lock into n + 1 small locks. n small locks on each Connection object and one lock on the ConnectionMap. Java 5's ReentrantLock (trylock())can be used to implement non-blocking mechanism.