Synchronized method

[born_free_77]

Hello All,

This is a question about a class which is a session bean and it has a method which is defined as synchronized. This class (which is a session bean) is extended by 2 classes which defines more concrete implementation for different workflow. My question is - does this violates the EJB specs. Beans are defined using EJB 2.1 specs.

Example code.

public abstract class MySuperClass extends SessionBean{

    public synchronized aMehod(){.....}

}

public class MyWorkflow1 extends MySuperClass{

     public void someEJBMethod(){

          super.aMethod()

     }

}

public class MyWorkflow2 extends MySuperClass{

     public void someEJBMethodHere(){

          super.aMethod()

     }

}

Do you think there will be issue/s with this implementation under heavy load (may be some batch job calls this workflow) Note that beans are not deployed in cluster.

Thanks,

[wdfink]

Yes, yes

synchronized is against the JEE specification

and

in my experience (I found such code in different applications and wrote it as beginner ;-) ) such code harm the throughput and during the time you spend a lot of time to analyze fuzzy behaviour regarding this.

A better approach will be to explain what you want and as for un-synchronized solution.

BTW, if you try to install a cluster the sync is gone because of the different JVMs ;-)

[born_free_77]

Thanks for the response,

This code is the existing code in an application which I was working. The app is deployed and it works fine but recently we have an issue with one of our batch process and some fail but most of them pass. My suspicion is this method which is marked as synchronized.

I was trying to find a test case to prove that synch method do harm, if any one know the test case pls let me know.

Thanks,

[born_free_77]

Som more info on the above ejb code.

MyWorkflow1 and MyWorkflow2 are defined as ejb using xdoclet.

MySuperClass extends SessionBean

someEJBMethod() is defined as ejb.interface method using xdoclet

aMehod() defined in super class is a public method and has no xdoclet defined.

[wdfink]

That is what I mean, unexpected behaviour under load.

I'm sure that your code work under 'normal' conditions, but this is one of the reasons why you do not use synchronized for EJBs.

What would help but falsified the result is a profiler (like jProfiler), but for such behaviour it is useless.

We have a good experience by using thread dumps and compare 2 or more dumps (e.g. 10sec gap) looking for blocked threads, you will find the blocking object via ID and you will see a number of threads waiting for this.

A general test case is not possible, you might stress this use case in a test environment and increase the parallel access, e.g. start with 1 and add 5 each minute. The result is a load profile which does not scale after a threshold.

hope this will be helpful

[born_free_77]

I wrote a test case to test this but was not able to see any undesired result.

I created 2 beans each extending abstract bean class which has synchronized method. Each bean calls that method by calling super.aMethod();

My controller class creates a custom class which is then submitted to a Executor service class which has thread pool defined.

I initially had only 20 threads in the pool and later I increased it.