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