Thanks Marcus for your update.
The locksize is configured already by our DB admin to this size. If I'm right the application which is throwing this exception is not the issue here. When the application 'B' is trying to update some data in DB, since the table is locked by the other application 'A' this application 'B' throws the deadlock error and roll back the transaction, which is perfectly fine. Now is there a way to find out what's causing this previous lock to DB. I mean is there a way to find which is the application 'A'? There are around 11 WAS applications (EAR's) in our system. Is there a way to find from DB which is this application or the statement which is making this lock so that we can ratify the problem.
Will the connection pool configuration of WAS datasource make any difference?
Any feedback or inputs is appreciated.