2014-01-07 4 views
0

У меня есть это действительно простая операция дао, которая работает довольно тонкая (часть теста JUnit):метка времени миллисекунды различие в действии Dao

for (int i = 0 ; i < 5000 ; i++) 
    mUserDao.saveUser(lUser, new Date().getTime()); 

второй параметр является отметкой о времени, пока значение. Я проверяю вид массового спасения.

Мой вопрос: теоретически возможно, что у меня есть две записи с тем же длинным значением в моей базе данных (mysql)? - в том же процессе.

Первый взгляд внутри отношения показывает мне разные длинные значения для каждого entrie (по крайней мере, последняя миллисекунда увеличивается).

Thx заранее

Стефан

+0

Если метод не синхронизируется, и если выполняются одновременные запросы, тогда метка времени такая же. –

+1

Взгляните на это http://stackoverflow.com/questions/4881448/safe-to-use-system-currenttimemillis-to-generate-a-unique-database-id – BobTheBuilder

+0

@Darshan Patel: синхронизировано –

ответ

1

Вы не можете гарантировать, что new Date() даст вам точное время точно. Часто это может быть неправильно примерно до 10 мс. Вызов new Date() использует System.currentTimeMillis(). Javadoc для currentTimeMillis() говорит

Возвращает текущее время в миллисекундах. Обратите внимание, что хотя единица времени возвращаемого значения равна миллисекунде, степень детализации зависит от базовой операционной системы и может быть больше. Например, многие операционные системы измеряют время в единицах десятков миллисекунд.

Так что это зависит от ОС. Мой опыт в том, что Windows особенно плоха в предоставлении точных дат.

И вы, конечно же, не можете гарантировать, что вы получите разные даты от последовательных звонков до new Date().

+0

есть библиотека, которая будет os независимый? –

+0

Я не уверен, что вы имеете в виду. JVM должна полагаться на ОС, чтобы рассказать ей время; оттуда ничего не получится.Поэтому, если ОС выдаёт неточные времена, JVM не может обойти это. –

1

Да, это возможно, особенно если вы испытываете быстрое аппаратное обеспечение, и что две спасательные операции выполняются в то же время. Тогда обе созданные записи будут иметь такое же длинное значение.

+0

глупый вопрос но могу ли я избежать этого: new Date(). getTime() + 1? –

+0

Нет, это не поможет. Лучший способ - использовать UUID класса, который генерирует новый идентификатор для каждого нового создания. вот документация http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html –

+0

да, но это не помогает моему для моего использования ... –

1

Я думаю, что миллисекунды с эпохи UNIX по-прежнему являются лучшим способом для измерения времени достаточно точным способом. Тем не менее, не очень хорошо иметь временную метку только в качестве первичного ключа. Пока у вас есть уникальный первичный ключ, вам действительно не нужны уникальные временные метки.

Если вы по какой-то причине хотите, чтобы временная метка была уникальной, вы можете применить «искусственный мазок». Например:

long last = 0; 
for (int i = 0 ; i < 5000 ; i++) { 
    long now = new Date().getTime(); 
    if (now <= last) { 
     now = last + 1; 
    } 
    last = now; 
    mUserDao.saveUser(lUser, now); 
} 

Есть много способов это можно улучшить, но приведенный выше код только для иллюстрации идеи мазка.

+0

Нет, это не мой первичный ключ –

Смежные вопросы