In threaded environments, multiple threads might be requesting a UUID at the same time.
This causes problems on JRuby where Array objects are not thread safe and calling
#pop was returning the same value to multiple threads!
Thanks for that, seems to make sense to me. However, I've never really been convinced about the next_uuid stuff when saving documents, I can't see the point when the database can do this for you without the use of mutexes. The save_doc  method is especially crappy with far too many rescues for older versions.
The reasoning for using UUIDs seems to be out of fear for proxies in the middle resending POST requests , I honestly cannot believe that is a problem, especially not for server to server calls.
Do you have a special use case for next_uuid or are you just trying to save documents?
I do not have a special use case for #next_uuid, I'm just saving new documents through couchrest_model. I was hoping to keep using UUID's as the unique identifier for documents in a particular database.
It would be great if I could just rely on CouchDB itself to assign the UUID on the server side. couchrest seems to use #put in the #save_doc method; I don't see why a proxy in the middle would resend that as a #post, but I don't have a super proficient understanding of HTTP.
Maybe we could simplify #save_doc to save the document right away, even if it has no _id set, and just leave #next_uuid for backwards compatibility?
Whoops, I didn't read the documentation correctly...we do want to use #post when there is no _id...hmmm
I think the best solution to this issue is simply to find an alternative way to generate UUIDs on the client. So I've done that instead.
Thank you for the pointers.
Use SecureRandom.uuid instead of fetching UUIDs from Couch
The solution to this problem, I think, is to use the standard Ruby library securerandom to generate all UUID's.
I changed my pull request accordingly, but now a test that depended on some mock data is failing. :(