this is regarding: http://tinyurl.com/nunmyu In order to be able to determine which tx should commit and which will rollback, I need to generate a coin toss for each node - a random number. In order to do that I'm thinking to use on of the following: 1) use java.util.Random . The issue with this class is that it has an undocumented behavior when it comes to concurrent access, so I cannot rely on it behaving correctly if I don't enforce proper synchronization. I'm afraid this might become a bottleneck as all the prepapares requests might want to synchronize on it. 2) Another approach would be to build an Random instance for each call. I made a test an the performance cost of new Random() + Random.nextLong is about 4 times bigger than call of random.nextLong only (on my laptop only), still about 15 mils for 1k creations 3) use System.nanos. Even though the conflicting tx are created at the same time, the chance for it to happen in the same nanosecond is very small, I would say. Don't know how this works for all architectures, though... Any feedback much welcomed! Cheers, Mircea _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

It turns out that it *IS* in-fact documented to be thread-safe: http://java.sun.com/j2se/1.5.0/docs/api/java/util/Random.html#next(int) However, it actually uses CAS in the impl. Jason T. Greene wrote: > Random is definitely thread-safe in the Sun derived JVMs, and > probably thread-safe in other JVMs. I would just use that. > > Otherwise you could implement MT: > http://en.wikipedia.org/wiki/Mersenne_twister > > Mircea Markus wrote: >> this is regarding: http://tinyurl.com/nunmyu >> In order to be able to determine which tx should commit and which >> will rollback, I need to generate a coin toss for each node - a >> random number. >> In order to do that I'm thinking to use on of the following: >> >> 1) use java.util.Random . The issue with this class is that it has >> an undocumented behavior when it comes to concurrent access, so I >> cannot rely on it behaving correctly if I don't enforce proper >> synchronization. I'm afraid this might become a bottleneck as all >> the prepapares requests might want to synchronize on it. >> 2) Another approach would be to build an Random instance for each >> call. I made a test an the performance cost of new Random() + >> Random.nextLong is about 4 times bigger than call of random.nextLong >> only (on my laptop only), still about 15 mils for 1k creations >> 3) use System.nanos. Even though the conflicting tx are created at >> the same time, the chance for it to happen in the same nanosecond is >> very small, I would say. Don't know how this works for all >> architectures, though... >> >> Any feedback much welcomed! >> >> Cheers, >> Mircea >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > >

this is regarding: http://tinyurl.com/nunmyu In order to be able to determine which tx should commit and which will rollback, I need to generate a coin toss for each node - a random number. In order to do that I'm thinking to use on of the following: 1) use java.util.Random . The issue with this class is that it has an undocumented behavior when it comes to concurrent access, so I cannot rely on it behaving correctly if I don't enforce proper synchronization. I'm afraid this might become a bottleneck as all the prepapares requests might want to synchronize on it.