Re: voyage/mongo randomly wrong OIDs
Posted by Henrik Sperre Johansen on Sep 02, 2013; 8:22am
URL: https://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4706071.html
On Aug 30, 2013, at 4:35 , Esteban Lorenzano <[hidden email]> wrote:
>
> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>>
>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <[hidden email]> wrote:
>>
>>> hi
>>>
>>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found.
>>> There are, of course, alternatives:
>>>
>>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow.
>>> 2) then you can use your own procedure in mongo... with same problem than (1)
>>> 3) you could use timestamp. but TimeStamps are slow :(
>>>
>>> anyway... I open to ideas :)
>>>
>>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision.
>>
>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way.
>>
>> What does the primitive actually do ? Is it different ?
>
> the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also.Wait, which primitive is this? UUID > primMakeUUID?
That code calls libUUID, which (as long as it doesn't crash :P) fetches from dev/urandom (or the windows equivalent RtlGenRandom), there shouldn't ever be a problem getting duplicate results unless those system-provided resources are bugged, in which case your entire system is borked.
The fallback code using UUIDGenerator default admittedly has a weak PRNG, and is dog slow:
gen := UUIDGenerator new.
[gen generateFieldsVersion4] bench '12,900 per second.'
[ UUID new ] bench '3,610,000 per second.' "Primitive working, btw"
but that hardly means you should run into duplicate sequential UUID's…
The *only* way sequentially equal UUID's could arise, is if one uses UUIDGenerator directly, and creates a new instance each time, which does indeed run the risk of returning values derived from the same Time initialization , but that should *never* be done…
Cheers,
Henry
URL: https://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4706071.html
On Aug 30, 2013, at 4:35 , Esteban Lorenzano <[hidden email]> wrote:
>
> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <[hidden email]> wrote:
>
>>
>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <[hidden email]> wrote:
>>
>>> hi
>>>
>>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found.
>>> There are, of course, alternatives:
>>>
>>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow.
>>> 2) then you can use your own procedure in mongo... with same problem than (1)
>>> 3) you could use timestamp. but TimeStamps are slow :(
>>>
>>> anyway... I open to ideas :)
>>>
>>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision.
>>
>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way.
>>
>> What does the primitive actually do ? Is it different ?
>
> the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also.
That code calls libUUID, which (as long as it doesn't crash :P) fetches from dev/urandom (or the windows equivalent RtlGenRandom), there shouldn't ever be a problem getting duplicate results unless those system-provided resources are bugged, in which case your entire system is borked.
The fallback code using UUIDGenerator default admittedly has a weak PRNG, and is dog slow:
gen := UUIDGenerator new.
[gen generateFieldsVersion4] bench '12,900 per second.'
[ UUID new ] bench '3,610,000 per second.' "Primitive working, btw"
but that hardly means you should run into duplicate sequential UUID's…
The *only* way sequentially equal UUID's could arise, is if one uses UUIDGenerator directly, and creates a new instance each time, which does indeed run the risk of returning values derived from the same Time initialization , but that should *never* be done…
Cheers,
Henry
signature.asc (859 bytes) | Free forum by Nabble | Edit this page |