Estoy usando System.currentTimeMillis() (que devuelve un número entero long) en Java para generar una ID única para entidades de base de datos ya que supongo que no es posible que estos tiempos se superpongan en ningún momento.¿Es seguro usar System.currentTimeMillis() para generar una ID de base de datos única?
¿Es esto una suposición segura?
Por ejemplo, en el momento me sale esto:
1296691225227
Es bastante poco probable que obtendrá un choque, sí (a menos que esté en un sistema de alta carga, en cuyo caso se trata de muy probable), pero aún es posible.
Java tiene un mecanismo existente para generar identificadores únicos, aunque - java.util.UUID. Tiene métodos para generar identificaciones aleatorias.
Sugiero usar eso en su lugar.
No, esto no es seguro. Un milisegundo es mucho tiempo en ciclos de CPU (se ejecutan en miles de millones de ciclos por segundo, no en miles), por lo que si entran varias solicitudes a la vez o si todos los subprocesos intentan crear entradas de base de datos, verán el mismo tiempo de CPU y terminará con llaves colisionantes. También tendrías problemas si el reloj del sistema de alguna manera se restableciera o cambiara a una hora anterior.
También vale la pena señalar que, si bien la granularidad * mínima * del temporizador de milisegundos es teóricamente de 1 ms, la granularidad real puede ser mayor. He usado sistemas en los que era 20 ms. –
sin mencionar algo como ntp moviendo el reloj hacia atrás. – jtahlborn
¿cuál es la granularidad mínima? ¿Cómo puedo verificar el valor de mi sistema? – piechuckerr
Si su código se ejecuta alguna vez en un entorno agrupado, aumenta las posibilidades de que tenga colisiones de id.
La mayoría de las bases de datos JPA tienen formas de generar identificadores únicos por sí mismos.
http://en.wikibooks.org/wiki/Java_Persistence/Identity_and_Sequencing
En términos de probabilidad de fallo, I duda el enfoque milisegundos sobreviviría la unidad de pruebas. – Dolph
@Dolph - o prueba de carga del sistema. Ciertamente no debería ... si los estás haciendo bien. –
Me gusta mucho el UUID pero es bastante ineficiente (entendido que por la manera más dura ...) la forma habitual de almacenar es UUID.toString() que es horrible 36bytes de longitud (generalmente mapeado a algo como varchar (36)). Los índices DB deben mantenerse en la memoria: cuanto mayor sea el índice, mayor será la memoria necesaria, también la indexación se ralentizará, etc. Aconsejaría utilizar algunos esquemas high-low con bits de agrupamiento y 'long' id. – bestsss