Tuesday, August 12, 2008

BPEL fails with WSIF exception on multiple simultaneous requests

Occasionally we run into what appear to be concurrency issues with BPEL whereby WSIF calls to our EJB are failing sporadically, reporting that the method we are trying to call cannot be found. Which is obviously incorrect because the deployed EJB has not been modified, and subsequent BPEL processes are not faulted. Usually we get this error when we are processing multiple records simultaneously.

Today I discovered the conditions that manifest the problem. If one of the BPEL processes is modfied and deployed and then - without refreshing the WSDL cache - two requests are processed concurrently, the first will always fail. If the WSDL cache is cleared, both are processed without problems.

So it appears to be a problem related to caching that only comes up if multiple requests are processed concurrently. So always refresh your WSDL cache after deploying BPEL processes to avoid any such issues.

<2008-08-12 13:19:50,125> <DEBUG> <default.collaxa.cube.ws> <WSIFInvocationHandler::invoke> Fault happened
org.collaxa.thirdparty.apache.wsif.WSIFException: No method named 'findSearchFile' found that match the parts specified
 at com.collaxa.cube.ws.wsif.providers.ejb.WSIFOperation_EJB.executeRequestResponseOperation(WSIFOperation_EJB.java:938)
 at com.collaxa.cube.ws.WSIFInvocationHandler.invoke(WSIFInvocationHandler.java:435)
 at com.collaxa.cube.ws.WSInvocationManager.invoke2(WSInvocationManager.java:443)
 at com.collaxa.cube.ws.WSInvocationManager.invoke(WSInvocationManager.java:251)
 at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__invoke(BPELInvokeWMP.java:727)
 at com.collaxa.cube.engine.ext.wmp.BPELInvokeWMP.__executeStatements(BPELInvokeWMP.java:366)
 at com.collaxa.cube.engine.ext.wmp.BPELActivityWMP.perform(BPELActivityWMP.java:195)

Friday, August 1, 2008

Extract the original entity from a (Hibernate) CGLIB proxy class

Ed: this is a rewrite of another post that deals with the same problem but with a less technical description.

If you have a polymorphic class structure then when Hibernate instantiates instances of your sub-classes and wraps them in a proxy class, the proxy is actually an instance of the root class in the hierarchy. This introduces some problems because you can no longer rely on instanceof and class casts because they will not work. You can implement a visitor pattern to work around these shortcomings.

The following code shows you how to retrieve the persisted concrete instance of your sub-class from the proxy class. This is useful for those occasions when you want access to the concrete instance, but don't want to implement a full visitor pattern:

if (proxy instanceof HibernateProxy){ 
   return ((HibernateProxy)proxy).getHibernateLazyInitializer().getImplementation(); 
}