Random default constructor uses nanoTime and a seed uniquifier (which follows a fixed value sequence), true. However these Xids are generated by the instance starting the transaction, so slaves as well. Xid global ids in neo4j are composed of random value and a sequence number that is incremented for every use. That's what happened that provoked this change - two slaves somehow managed to generate the same Xid, i.e. they were started with the same seed (before this commit we used new Random( currentTimeMillis() ), or rather the XidImpl class was loaded the exact same milli.

This commit adds serverId to the globalId, i.e. extends it 4 bytes so that two instances cannot do this anymore.

Even if this change will prevent this issue to happen again, do you think we should base the random seed on something else, like SecureRandom to generate a seed?