Здравствуйте, ssvg, Вы писали:
S>Добрый день
S>Подскажите если кто знает S>возможно ли в MS SQL 2005 синхронное выполнение процедур S>(т.е. в один момент времени процедура должна выполнялась лиш для одного пользователя) S>порядок обработки запросов к данной процедуре не важен
S>Заранее большое спасибо.
Подскажите если кто знает
возможно ли в MS SQL 2005 синхронное выполнение процедур
(т.е. в один момент времени процедура должна выполнялась лиш для одного пользователя)
порядок обработки запросов к данной процедуре не важен
ssvg wrote: > возможно ли в MS SQL 2005 синхронное выполнение процедур > (т.е. в один момент времени процедура должна выполнялась лиш для одного > пользователя) > порядок обработки запросов к данной процедуре не важен
глупостьтокакая....
Что-то мне подсказывает, что нужно что-то совсем другое.
Посвяти нас в то, нафига оно тебе, и мы постараемся тебе дать совет как
правильно это сделать.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, Ромашка, Вы писали:
Р>глупостьтокакая....
Р>Что-то мне подсказывает, что нужно что-то совсем другое. Р>Посвяти нас в то, нафига оно тебе, и мы постараемся тебе дать совет как Р>правильно это сделать.
Необходимо чтобы процедура (или функция) раздовала уникальные значения
зависящие от времени + const (упрощенно говоря)
а если 2 пользователя одновременно вызовут эту функцию (процедуру)
то получим одинаковое значение.
S>Необходимо чтобы процедура (или функция) раздовала уникальные значения S>зависящие от времени + const (упрощенно говоря) S>а если 2 пользователя одновременно вызовут эту функцию (процедуру) S>то получим одинаковое значение.
Точность DATETIME — 3.33 мс. Что если если процедура будет отрабатывать настолько быстро, что время не успеет измениться между двумя её вызовами?
А обеспечить синхронное выполнение процедур можно через блокировки.
Здравствуйте, ssvg, Вы писали:
S>Здравствуйте, Ромашка, Вы писали:
S>Необходимо чтобы процедура (или функция) раздовала уникальные значения S>зависящие от времени + const (упрощенно говоря) S>а если 2 пользователя одновременно вызовут эту функцию (процедуру) S>то получим одинаковое значение.
Раздавать Guids не подойдет? newid() тоже, вроде, уникальные значения возвращает
Здравствуйте, Дюша, Вы писали:
S>>Необходимо чтобы процедура (или функция) раздовала уникальные значения S>>зависящие от времени + const (упрощенно говоря) S>>а если 2 пользователя одновременно вызовут эту функцию (процедуру) S>>то получим одинаковое значение.
Д>Раздавать Guids не подойдет? newid() тоже, вроде, уникальные значения возвращает
Точно. А если надо, чтоб каждый следующий GUID был больше предыдущего, то используйте newsequentialid()
Здравствуйте, Crimzic, Вы писали:
C>А обеспечить синхронное выполнение процедур можно через блокировки.
А лучше так:
create table LastNumber(
Num int primary key
);
GO
insert LastNumber values(0);
GO
declare @NewNum int;
update
LastNumber
set
@NewNum = Num = Num + 1
;
select @NewNum;
Здравствуйте, Crimzic, Вы писали:
S>>Необходимо чтобы процедура (или функция) раздовала уникальные значения S>>зависящие от времени + const (упрощенно говоря) S>>а если 2 пользователя одновременно вызовут эту функцию (процедуру) S>>то получим одинаковое значение. C>Точность DATETIME — 3.33 мс. Что если если процедура будет отрабатывать настолько быстро, что время не успеет измениться между двумя её вызовами?
естественно реальный алгоритм это предусматривает. C>А обеспечить синхронное выполнение процедур можно через блокировки.
Я искал более красивый вариант
Гм... Можно поиграться с SERIALIZABLE транзакциями: хранить последнее значение счетчика в отдельной таблице — и в транзакции увеличивать и селектить его.
Здравствуйте, Mr.Cat, Вы писали:
MC>Гм... Можно поиграться с SERIALIZABLE транзакциями: хранить последнее значение счетчика в отдельной таблице — и в транзакции увеличивать и селектить его.
В SERIALIZABLE нет никакой необходимости. Если конечно быть внимательным и читать всю ветку, то можно было бы заметить, что способ предложеный мной здесь
, > прекрасно работает в read commited и даже без внешней транзакции.
Ессно без внешней транзакции. С внешней транзакцией, даже read
committed, он попросту стопит все остальное, что пытается получить новый
идентификатор. Тормоза возможны жуткие. Так что ребята юзайте
autoincrement, благо он внетранзакционный.
Posted via RSDN NNTP Server 2.1 beta
Всё, что нас не убивает, ещё горько об этом пожалеет.
Здравствуйте, ssvg, Вы писали:
S>Здравствуйте, Ромашка, Вы писали: Р>>глупостьтокакая.... Р>>Что-то мне подсказывает, что нужно что-то совсем другое.
S>Необходимо чтобы процедура (или функция) раздовала уникальные значения S>зависящие от времени + const (упрощенно говоря) S>а если 2 пользователя одновременно вызовут эту функцию (процедуру) S>то получим одинаковое значение.
ну и в копилку глупых решений глупой проблемы — используйте Extended SP с реализацией блокировки на уровне OS(семафоры, мютексы и пр.)
Здравствуйте, Спильный Андрей, Вы писали:
СА>ну и в копилку глупых решений глупой проблемы — используйте Extended SP с реализацией блокировки на уровне OS(семафоры, мютексы и пр.)
Extended здесь не нужны. Вполне достаточно штатных sp_getapplock/sp_releaseapplock.
Здравствуйте, Ромашка, Вы писали:
Р>Ессно без внешней транзакции. С внешней транзакцией, даже read Р>committed, он попросту стопит все остальное, что пытается получить новый Р>идентификатор. Тормоза возможны жуткие.
Ну это понятно — в этом случае будет установлена updlock.
Р>Так что ребята юзайте autoincrement, благо он внетранзакционный.
Не всегда возможно. Если мне надо обеспечить именно последовательность для нескольких таблиц?
ssvg wrote:
> Необходимо чтобы процедура (или функция) раздовала уникальные значения > зависящие от времени + const (упрощенно говоря) > а если 2 пользователя одновременно вызовут эту функцию (процедуру) > то получим одинаковое значение.
А зачем эти 2 вещи объединять? Сделать 2 поля: время — обычный
timestamp, уникальное значение — суррогатный pk, обычный autoincrement
или sequence. Пара этих полей будет гарантированно уникальной, т.к.
инкрементное поле гарантированно уникальное.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ромашка, Вы писали:
Р>_d_m_ wrote: >> Не всегда возможно. Если мне надо обеспечить именно последовательность >> для нескольких таблиц?
Р>Не сочтите за наезд, а можно пример, когда такое может понадобиться?
Ну я навкидку не скажу. Еще такая возможность необходима, когда требуется несколько последовательностей для одной таблицы. И с этим я сталкивался. И решал именно так, как показал выше.
