Interaction problem with BlazeDS and Eclipselink 2.x when a Transaction Rollback occurs

Question

I'm cross posting this here in the hopes that it might help someone else with a similar problems.

We have been dealing with this bug for a while and really took a lot of time and a second set of eyes to figure out what was happening here.
We have a web based system deployed on Weblogic which uses Spring Framework to manage our business tier, and Flex for our web clients. We provide our service object layer directly to Flex clients through AMF remote object serialization and usually let the default exception handling in Spring do its thing.

When invoking a remote object through BlazeDS which starts and subsquently rolls back a transaction, BlazeDS attempts to acquire as much information about the Exception Chain as possible and then serializes it to the Flash client. In doing so, it gets an instance/ or instances of ClassDescriptor (on the object that caused the rollback). It then attempts to use JavaBeans type semantics on the ClassDescriptor invoking getInheritancePolicy(), without using the hasInheritance() descriptor check. After this happens, the entire app tier becomes unusable as the entity/entities ClassDescriptors now have an unusable InheritancePolicy object for non inheritance entities.
This can be quite a maddening experience, especially in production, as in our experience, one rollback causes all other clients using our system to be locked out until we restart Weblogic.

We have looked all over the Internet to see if anyone else has experienced this issue, and have found nothing so far. We hope this post can help others.

You can get around the problem by changing the amf channel definition in the web app's services-config.xml by adding a
<serialization>
<legacy-throwable>true</legacy-throwable>
</serialization>
property to the properties section.

A subsequent rollback here will not cause the methods inside ClassDescriptor to be called and the server side of the system will remain stable. However, you will encounter another bug within BlazeDS: Infinite Recursion. We are attempting to submit a patch for this as well, but the client will not die because of it. It will just never receive the fault message.

Another solution is to ensure that any service method exported as a remote object invocation has a try-catch block that throws a different exception that doesn't include the exception hierarchy in the new exception. This isn't an easy option for us, since we would have to rewrite quite a bit of code.

true

property to the properties section. A subsequent rollback here will not cause the methods inside ClassDescriptor to be called and the server side of the system will remain stable. However, you will encounter another bug within BlazeDS: Infinite Recursion. We are attempting to submit a patch for this as well, but the client will not die because of it. It will just never receive the fault message. Another solution is to ensure that any service method exported as a remote object invocation has a try-catch block that throws a different exception that doesn't include the exception hierarchy in the new exception. This isn't an easy option for us, since we would have to rewrite quite a bit of code.

dcollie · Answer

Thanks for posting your problem and investigation, I came across the same issue and built upon your research.

From it, I found a solution to the problem involving controlling the serialization of the EclipseLink OptomisticLockException via the PropertyProxyRegister/BeanProxy classes, and specifically omitted the SESSION and QUERY atributes which seemed to be the offending classes causing the Runtime exception.

I posted details over here: http://www.eyelock.net/blog/post.cfm/controlling-serialization-of-java-objects-in-lcds-or-blazeds

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded