This may not really be really scalability issue...
I am facing a dead lock problem in EJBs.
Our application has architecture something like this...
All manager beans (stateless session beans) talk to core beans (entity beans). We expose only API of managers to clients. Right now there is only one type of entity EJB (instances of same EJBs).
All methods in managers modifying core beans have 'Required' attribute and all methods of core beans which modify database have 'Mandatory' attribute.
All methods which retrieve data have 'Not Supported' attribute (managers as well as core beans).
But when I run the application with just 6 simultanious users, I get 'dead lock detected' exception.
Of course I am trying to test it with different attributes, but if someone already knows the cause and solution of the problem please let us know. We are desparately looking for it as our application is stuck without it.
Thanx in advance.
Hi Unicman ,
Are you using Weblogic 4.5.1 for deploying your beans ?
If yes , then there is no soultion for this problem .
This problem exits because weblogic uses it's own locking system.
But this problem is solved in weblogic 6.0 .So if you can port u r system on 6.0 then this problem will not be there any more otherwise there is no soultion to this problem.
We're also in this paticular situation. Many unexplained deadlocks from the DB. I've tried to manually do "Lock Table" commands in the DB but I'm still suffering from deadlocks when more than 5-6 users are doning the 'same' tasks at once. A DB-trace tells me that the deadlocks occus all around in the database. I can't get problems i any particular tables.
And, Yes, I'm using 4.5.1. Now I need to tell my projectmanager exactly why we can't continue on 4.5.1 and I found your answer a bit vague. Could you please specifiy why deadlocks occur, and from where you got this information. I've talked to BEA-people in Sweden and they can't confirm your statement.
regards ... Jocke
Are you locking multiple tables in a different order from the session bean layer, for example in some cases you lock A then B and in another you lock B then A? If that is the case you could prevent the deadlocks by using a well-defined locking order.
My understanding of BEA is that it uses its own internal locking of entity beans (most app servers rely on the database to lock), so perhaps Abhijit Gaikwad is saying that the internal locking mechanism in BEA 4.5.1 does not have deadlock detection? I don't have access to it so I can't test that hypothesis.
In all of the SQL databases I know of if a deadlock occurs, it will be detected and the involved transactions rolled back. This could cause some serious performance problems for your application (think ethernet collisions under high traffic), but it would still be better than deadlock. Using a predefined locking order would fix this as well.