ObjectId currently uses timestamp and a machine id obtained using network stuff and a third part obtained trying to get the "name" of the currently running JVM.

These three elements will always return the same tuple, in the same second, for the same virtual machine (as long as the RuntimeMXBean is available).

Unfortunately, it will return the same tuple if two different classloaders (say, two different webapps) are active in the same JVM.

The fourth element, the progressive counter, is taken from a static variable, so it's relative to the single classloader, not the entire JVM.

This means that ObjectId could create two identical IDs if called from two different webapps, when both webapps try to write during the same second. If this happens on the same collection, this will cause errors.

It seems like a very rare situation, but unfortunately it seems like this happened to me a couple of times, cause I was experimenting on using MongoDB to collect informations from different webapps, some of them running on the same Tomcat instance, and all writing more or less at the same time a log message on the same collection of the same db. The log message was to log that they were starting.

The collision happened while the counter was rather low (below 100), probably on the long run the different counters in different classloaders will tend to diverge, but it's still a matter of randomness.

A simple solution could be to add (xor or whatever) the System.identitiyHashCode of the current classloader to the processPiece, considering that in the progressive counter is relative to the classloader and that in a multiple classloader setup (like a web server) the closest match for "process context" is actually the classloader.