Sto usando System.currentTimeMillis() (che restituisce un numero intero long) in Java per generare un ID univoco per le entità del database poiché presumo che non sia possibile che queste volte si sovrappongano in qualsiasi punto.È sicuro utilizzare System.currentTimeMillis() per generare un ID di database univoco?
È un presupposto sicuro?
Per esempio, in questo momento ottengo questo:
1296691225227
E 'abbastanza improbabile che si otterrà uno scontro, sì (a meno che non sei in un sistema ad alto carico, in questo caso si tratta di molto probabile), ma ancora possibile.
Java ha un meccanismo esistente per la generazione di identificativi univoci, tuttavia - java.util.UUID. Ha metodi per generare ID casuali.
Suggerisco caldamente di usarlo.
No, questo non è sicuro. Un millisecondo è un tempo lungo nei cicli della CPU (funzionano a miliardi di cicli al secondo, non migliaia), quindi se più richieste arrivano alla volta o se più thread tentano tutti di creare voci del database vedranno la stessa CPU e finirà con le chiavi in collisione. Avresti anche problemi se l'orologio di sistema in qualche modo è stato ripristinato o modificato in un momento precedente.
Vale anche la pena notare che mentre la granularità * minima * del timer in millisecondi è teoricamente pari a 1 ms, la granularità effettiva potrebbe essere maggiore. Ho usato sistemi in cui era 20ms. –
per non parlare di qualcosa come ntp che sposta l'orologio all'indietro. – jtahlborn
qual è la granularità minima? Come posso controllare il valore del mio sistema? – piechuckerr
Se il codice viene eseguito in un ambiente cluster, aumenta le probabilità che si verifichi una collisione di identificazione.
La maggior parte dei database JPA ha modi per generare autonomamente ID univoci.
http://en.wikibooks.org/wiki/Java_Persistence/Identity_and_Sequencing
In termini di probabilità di guasto, dubito l'approccio millisecondi sarebbe sopravvissuto unit testing. – Dolph
@Dolph - o test di carico del sistema. Certamente non dovrebbe ... se le stai facendo correttamente. –
Mi piace molto UUID ma è piuttosto inefficiente (inteso nel modo più duro ...) il modo usuale di memorizzare è UUID.toString() che è lungo 36 byte (solitamente mappato a qualcosa come varchar (36)). Gli indici DB dovrebbero essere tenuti in memoria - più grande è l'indice, più memoria è necessaria, anche l'indicizzazione si rallenta, ecc. Suggerirei di usare alcuni schemi high-low con bit di cluster e 'long' id. – bestsss