We have implemented a work-around that seems to eliminate the thread deadlocks that we
were experiencing.
Basically, instead of sending a PortProfileRequest entity along with the complete serialized tree
of referenced entities, here's what we did:
1. Just before sending the PortProfileRequest from the client to the JMS queue, we get the
primary keys for all referenced entities and then set those entities to null. There are three
entities referenced: one Port entity and two DslProfile entities. It is these entities that normally
resulted in the large serialized object tree when sending via JMS.
2. The PortProfileRequest (with null entities) and three primary keys are put into a wrapper object
that is sent via JMS. After sending the JMS message successfully, the PortProfileRequest
entity references are restored to allow further processing on the client side.
3. On the receiving end, the message-driven bean calls an EJB method that does the following
all within a single UserTransaction:
a. Find each of the three referenced entities given their primary keys
b. Reattach the entities to the PortProfileRequest
c. Persist the PortProfileRequest
d. Call EntityManager.flush() to update the auto-generated primary key for PortProfileRequest.
I assume that re-finding the entities on the server side eliminates the extensive merging that
was occurring when such a large number of detached entities were sent at one time.
[Message sent by forum member 'skalynuk' (skalynuk)]
http://forums.java.net/jive/thread.jspa?messageID=250195