IBM "encourages" PHP for Web software

Today zdnet reports that IBM backs PHP for Web software development. The article also suggests that this move by IBM is based on Java's inability to easily access IBM back-end but wont move out from supporting Java for large enteprise applications through its WebSphere product line.

Access Your PcAnywhere for Free!

I tried this service http://www.mywebexpc.com/ and its great! You could access your PC from Anywhere for FREE! Its worthy trying!

Concurrency Control and Application Performance

Concurrency Control is one of the most common phrases used in the world of resource sharing. In WebSphere its for sharing data resources. There are two major schemes used in concurrency contorl: pessimistic and optimistic. The pessimistic approach locks the resources early in the transaction i.e. at the start of a transaction. So the resource will almost be locked for the period of this transaction. For long transactions this approach is not generally desirable. In optimistic approach the resource is locked only at the final phase of the transaction. In this approach during the commital phase check is made to see if the data hasn't changed since the begining of the transaction. If no change is made then lock is acquired and transaction is commited or else the transcation is rolled back. To read more about Concurrency scheme in IBM WebSphere click here.

The locked resource cannot be accessed by other contending requests hence affects the avalabiltiy of the resource. Since the lock period is long in the pessimistic approach it would greatly affect the speed of the application interms of user experience. It is a good idea to set investigate and change the access intents in a method level fashion and not just leave in the default PessimisticUpdate intent.

Websphere 5.1 - Access Intent

Today I was fighting with a bug while migrating an webapp from WAS 5.0 to 5.1. One of the EJB had a finder method which had a join query. So whenever this particular method is called during runtime it would throw this exception:

com.ibm.ws.ejbpersistence.utilpm.PersistenceManagerException: PMGR1001E: No such DataAccessSpec :FindMeetingTemplatesByPropId. The backend datastore does not support the SQLStatement needed by this AccessIntent: access intent: (pessimistic update-weakestLockAtLoad)(collections: transaction/25) (resource manager prefetch: 0).

After investigation its found that its due to the Default Access Intent which is PessimisticUpdate-WeakestLockAtLoad. For join queries in Oracle backend this Update access intent wont work. Generally this access intent must be used for UPDATE...WHERE.. queries. To fix this in EJB Deployment Descriptor :

1. Goto Access
2. In Access Intent for Entities 2.x (Method Level) -> Add wsPessimesticRead intent with the method that is faulting.
3. Restart your server and thats it.. the bug is fixed!

I also think its a good idea to know about Concurrency Control.

Handling east asian (Japanese, Chinese,Hindi,Tamil etc) languages input from browser

If you are working on an internationalization project and need to get input from the browser in mutliple languages and have problems with that, then you may need to read further.

The most common encoding used for east asian languages is UTF-8. When a page is rendered from the server side it is easy to set the pageEncoding to UTF-8 and send using
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>

But for the input text from the browser the type of encoding used cannot be unfortunately set by the server. But we may have to generally assume it to be UTF-8. So before doing request.getParameter("field") we must setEncoding to UTF-8 using
request.setCharacterEncoding("UTF-8")

Here the assumption is that the browser is using UTF-8 and so do we. It should work fine for Wester European langauges even if the encoding used is ISO-8859-1 or US-ASCII.

You could also explicitly change your browser's encoding to UTF-8 in IE by View -> Encoding -> UTF-8

Microreboot

Couple of days before I mentioned I came across the concept of ROC (Recovery Oriented Computing). Today, I came across one of its research paper about Microreboot technique that can be employed for enterprise applications at a component level. They have taken JBoss J2EE application server and have implemented and tested this concept. Their idea is that most of the problems are resolved on a restart (or reboot in other terms) of the application server or the physical machine itself. But such reboots are fairly costly interms of downtime so the idea of microreboot is to boot individual components of the application (for example EJBs or WAR files in J2EE). By such microreboot all exisiting references of a component including resources including threads are destroyed and recreated. The Classloader of individual components themeselves are not destroyed in such a reboot, so static variables wont be re-intialized.

EJBs they cant be rebooted individually because they may maintain references to other EJBs that can span across containers. Thus, whenever EJBs are microrebooted the entire group of EJBs will be microrebooted. To determine this group the information is obtained from deployment-descriptors.

Their results show that there is significant improvement in recovery time while perseving the functional distruption, application state and cluster load dynamics. In order for to have microreboot the application must be carsh-only.

At this point I dont know the cost of making an application crash-only. Depending on the cost of writing cash-only software we can determine how effective this idea would be for businesses! I would want to explore that in the future.

Refere: Microreboot - A Technique for Cheap Recovery

Google Maps!

Here you go.... Its just fascinating!

High Availability or Fast Recovery?

I came across an interesting research topic Recovery-Oriented Computing at UC Berkely. The research project that is investigating novel techniques for building highly-dependable Internet services. Generally the trend is to provide High Availability for Web based applications using Clustering and Load-balancing. The idea of ROC suggests faster reocvery instead of fail-safe. Business could favour this idea mainly depending on cost of failure and the cost(also time) for recovery. If the time for recovery can be minized in such a way that could fit cost of failure business model this concept could be a great success!

I remember this saying "History repeats itself". If we see ROC or Binary XML both are like revisiting the past with a different perspective. People were using Recovery mechansims before the buzz of HA and same with binary xml which is now a tailored solution for network traffic!

Fast XML -- Binary XML ??

There is always a concern on the speed and size of XML though people undoubtedly hail XML's interoperatbility. But with these concerns now there is a new and emerging concept called Binary XML (Refer : Fast Infoset Project). If Binary XML develops there is a possibility that interoperability may not be possible. There are also effort to create standardized Binary XML format, possibility of which remains to be seen. I feel that the interoperability is the greatest advantage of XML and must be preserved at any cost. Lets see how the show turns up!

Desktop Search - Copernic

I find this Copernic Desktop Search better than Google and MSN! Finding music, videos, photos, PDF, DOC, XLS etc is easy. But must be configured properly so that it wont peg your CPU all the time.

Environment varible size in Windows

How to get around the problem of environment variable size in Windows?

Sometimes we may need to set PATH variable (or anyother variable) but the content may be "large" (max 255 characters in some flavours of Microsoft Windows). In order to over come this we can use subst command.

subst is a command to assign a Virtual drive for the given path. For example

subst m: C:\myproject\classes

The set CLASSPATH=m:;C:\otherproject\classes;C:\vendor1\classes;
C:\vendor2\classes;.... ..... .... ... ........

Thanks to Bagath for this input!

UTF8 Encoded data

Today I faced the problem of storing Japanese characters in ResourceBundles (Struts framework/Java). The Japanese characters are in UTF-8 encoding (which is ofcourse variable-length encoding scheme) are 3 bytes. So they cant be obviously stored in TXT files which uses some Latin based encoding schemes (which consider characters are 2 bytes). So only way to store them is store them as encoded utf data. To convert to utf encoded format I used the tool native2ascii which comes with JDK.

Before Conversion
今すぐ予約

After conversion using native2ascii
\u4eca\u3059\u3050\u4e88\u7d04