We are currently using a statefull session bean to access (via COM+) a non thread-safe application. The way we tried to protect the critical session was:

public class SessionEJB ....

private final static String Semaphore = "";

public void calculate() {
   ....
   synchronized (Semaphore) {
        .. goto the COM application and perform the non-thread safe stuff
   }

   ...
}

read the ... as more (possibly) non-relevant java code.

This works fine some-times, but mostly results in transaction rollbacks due to a time-out. It looks as if we have a ded-lock on our hands. How come? I know the spec says not to have synchronization in the code: I can imagine that this doesn't work on partinitioned servers, but we use a single machine, single VM. Implemented on Websphere AS 3.5.3.

Any ideas/solutions?

Thanks a lot for thinking with me!

Paul de Reus

Since you declared the semaphore variable as static, all instances of the bean will be blocking on the same semaphore. It looks like this is what you want, since all beans call one resource (via COM), but I would perform the following experiment: set the bean pool size to one, and put the System.out.println statements before and after the COM call (inside the synchronized block), to see if the call works ok. If this works, try to increase the pool size to 2, and see if the problem occurs. I would check the timeout on the COM call and compared it to the amount of time actually spent on waiting.
Also, you might want to put some println statements in ejbActivate/ejbPassivate methods, to see if your bean gets destroyed/created. That would mess up any thread waiting on the semaphore, I guess. I think it's possible to tell websphere not to passivate beans, I think we were doing something like this on the occasion.
Those are just suggestions, hth.

Martin

Why do you need to have a critical section in a stateful session bean (SFSB)? A SFSB is only meant to be accessed by a single-client in its whole life. Even if multiple clients were able to get a handle to it, only 1 client can enter your method at the same time and another client would receive an exception from the EJB container.

It is not the session bean that is critical but the COM application it uses. Synchronization cannot be done on the COM app, so I have to find a mechanism to synchronize calls to it (i.e. in the session bean).

Thanks for thinking with me!

You could build an apartment-model COM+ component that delegates to your COM+ current component. Then from your SessionBean call the delegator. No need to use synchronize in the bean.

As per EJB specs, you are not allowed to use 'synchronise'. Any thread management by the bean provider is not allowed in EJB.

I think what you really want to do is use a Java/COM bridge like JIntegra. You will be able to synchronize control from the Java side.

I think what you really want to do is use a Java/COM bridge like JIntegra. You will be able to synchronize control from the Java side.