I've attached modified versions of the entity classes involved. The essence of the data
model is intact, but I've had to remove the core logic (except for hashCode() and equals())
and the NamedQueries annotations for confidentiality reasons.
A rough summary of the data model, with <-> representing a bi-directional relationship and
-> representing a unidirectional relationship, is as follows:
NodeModel <-> Node
NodeModel <-> DslProfile
Node <-> Card
Card <-> Port
Port <-> PortAssignment
PortAssignment <-> AssignedService
PortProfileRequest -> DslProfile
PortRequest -> Port
There are also three classes in an inheritance hierarchy:
PortProfileRequest extends PortRequest
PortRequest extends ScheduledRequest
Here's the scenario where the problem occurs:
1. In an application client, a number of new PortProfileRequest entities are created.
Each PortProfileRequest references other detached entities (DslProfile, Port, etc.)
that have been preloaded from the database, so the only new non-persisted entity
is the PortProfileRequest. Every other detached entity already has a valid
primary key.
2. Each PortProfileRequest is sent in serialized form to the message queue as part
of an ObjectMessage. Each individual PortProfileRequest will be referencing
(via PortRequest->Port->Card->Node) the same Node entity, and the Node typically
has more than a thousand Port entities (referenced via multiple Card entities),
so the serialized tree is quite large.
3. Since we have specified a maximum of 128 ScheduledRequestWrite message-driven bean
instances, the multiple ObjectMessages are most likely being processed in parallel.
4. On receipt of an ObjectMessage with a serialized PortProfileRequest, the
ScheduledRequestWrite message-driven bean begins the UserTransaction, calls
persistAndUpdatePrimaryKey(), and then commits the UserTransaction.
5. The UserTransaction.commit() call never returns.
[Message sent by forum member 'skalynuk' (skalynuk)]
http://forums.java.net/jive/thread.jspa?messageID=244163