There are many cases where the UserTransaction.commit() call completes successfully.
We have other ScheduledRequest sub-class entities that successfully make it through
almost identical paths (such as the PortFreezeRequest handling that can be seen in the
ScheduledRequestWrite source code).
In fact, we have one application client that generates very large volumes of PortProfileRequest
entities in a short period of time. That was the scenario that was described at the beginning
of this thread that is now fixed. In that other scenario, many thousands of
PortProfileRequest objects are successfully persisted to the database (using the same
persistAndUpdatePrimaryKey() method called from the same ScheduledRequestWrite
message-driven bean), but a small number never made it through. With the fix in place, I
haven't seen this occur in over a week now.
The main difference between the two scenarios seems to be this:
Scenario 1 (now fixed):
* A new PortProfileRequest is prepared with references to an existing Port entity (via the
PortRequest super-class) and the two existing DslProfile entities required (toProfile and
fromProfile)
* Since there is a reference from PortProfileRequest->Port->Card->Node, there was the
potential to needlessly serialize the Node->Card collection, and each Card->Port collection,
so we cleared the Node's Card collection, and each Card's Port collection, before serializing
the PortProfileRequest. In this situation, pruning the object tree in such a way was possible
since the entities would no longer be used in the code. This resulted in a much smaller
serialized object tree and reduced the JMS message size considerably. I guess it
also reduced the number of objects that TopLink needed to traverse when the
PortProfileRequest entity was persisted.
Scenario 2 (still an issue):
* A new PortProfileRequest is prepared with references to an existing Port entity (via the
PortRequest super-class) and the two existing DslProfile entities required (toProfile and
fromProfile)
* Since this situation does not allow the same pruning of the object tree, the
PortProfileRequest->Port->Card->Node reference results in all the Node's Card entities and
every Card's Port entities being serialized into the ObjectMessage. So, when it comes
time to persist the PortProfileRequest entity, I'm guessing that TopLink has to traverse
a much larger number of entities than scenario 1.
[Message sent by forum member 'skalynuk' (skalynuk)]
http://forums.java.net/jive/thread.jspa?messageID=244181