Thanks for your response Siva, here is what I have since found:
I am in fact using CMT
I modified glassfish to only allow a single instance of the MDB. I verified this was working by putting a static counter which would increment upon each instantiation of the MDB, and it stayed at 1.
I then also had the MDB output the one field of the ObjectMessage it receives which is currently distinctly identifying each object - nanoseconds since epoch. I have confirmed that no object in the dataset I am testing with has matching values.
The coworker who wrote our "JMS Driver" also modified his to output the nanoseconds value upon sending the object to the JMS Topic. We then ran it at a rate of 20 ObjectMessage's/second.
After a while, the MDB spit out a debug statement that it had found in entity in the DB that it had intended to insert (no EntityExistsException this time because we don't have multiple instances of the MDB entering a race condition in the find()/persist() code.
We looked at the output of the JMS Driver and the output of the MDB for the violating nanosecond value. The JMS Driver sent the object containing that value once, the MDB received the object containing that value twice.
Therefore, JPA appears to be working as expected at this point. It appears as though it is either JMS spawning off duplicate messages, or somehow the EJB container is grabbing the same message multiple times.
To be sure, I updated my Glassfish V2 server to Glassfish V2u1. Tried it again, and now I also get the below exception:
"DirectConsumer:Caught Exception delivering messagecom.sun.messaging.jmq.io.Packet cannot be cast to com.sun.messaging.jms.ra.DirectPacket"
However the data is still being persisted and I still get the duplicate message incident.
Any ideas?
[Message sent by forum member 'jamesdh' (jamesdh)]
http://forums.java.net/jive/thread.jspa?messageID=268392