Как предотвратить возникновение исключения при попытке нарушения ограничения уникальности вследствии одновременного добавления записей двумя клиентами?

В общем случае и в частности для:
Microsoft Access 2002, ADO.NET, ASP.NET

Здравствуйте, igna, Вы писали:

I>Как предотвратить возникновение исключения при попытке нарушения ограничения уникальности вследствии одновременного добавления записей двумя клиентами?

I>В общем случае и в частности для:
I>Microsoft Access 2002, ADO.NET, ASP.NET

Можно поконкретнее: проблема в том как смоделировать таблицу или как на уже готовой таблице избежать нарушения ограничения уникальности?

Если проектирование, так это делается через числовые последовательности. Эти последовательности или предоставляются базой данных (например sequence в Оракл) или ведутся разработчиком в отдельной таблице. В случае отдельной таблицы клиенты считывают записи с их одновременной блокировкой (select for update).

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

Здравствуйте, psc, Вы писали:

psc>В случае готовой таблицы избежать этого нельзя, если не блокировать всю таблицу.

Как заблокировать таблицу имея ADO.NET и Microsoft Access 2002?

Здравствуйте, igna, Вы писали:

I>Как заблокировать таблицу имея ADO.NET и Microsoft Access 2002?

Конкретно для ADO.NET и Microsoft Access 2002 я не пробовал, но в книге David Sceppa "Programming ADO" описан способ установки Isolation level. Если интересно могу выслать электронный вариант книги.

Здравствуйте, psc, Вы писали:

psc>В случае готовой таблицы избежать этого нельзя, если не блокировать всю таблицу.
Ну я бы не был так категоричен.

Здравствуйте, igna, Вы писали:

I>Как предотвратить возникновение исключения при попытке нарушения ограничения уникальности вследствии одновременного добавления записей двумя клиентами?
Аэээээ... Не нарушать
В каждой СУБД есть свои механизмы, как в Access'е — не знаю..

Здравствуйте, psc, Вы писали:

psc> ... в книге David Sceppa "Programming ADO" описан способ установки Isolation level. Если интересно могу выслать электронный вариант книги.

Интересно. Адрес в личных данных. Заранее спасибо.

Но я пробовал транзакцию с уровнем изоляции Repeatable Read, получил сообщение что Jet.OleDb его не поддерживает.

Здравствуйте, Merle, Вы писали:

M>Аэээээ... Не нарушать
M>В каждой СУБД есть свои механизмы, как в Access'е — не знаю..

А в MS SQL Server какие, знаешь?

Здравствуйте, igna, Вы писали:

I>А в MS SQL Server какие, знаешь?
В MSSQL знаю.. IDENTITY столбцы для PK.
В кчестве универсального способа, подходящего практически для любого сервера, можно предложить использовать GUID сгенеренный на клиенте, как уникальный ключ.

Здравствуйте, Merle, Вы писали:

M>В MSSQL знаю.. IDENTITY столбцы для PK.
M>В кчестве универсального способа, подходящего практически для любого сервера, можно предложить использовать GUID сгенеренный на клиенте, как уникальный ключ.

Прошу прощения, возможно я не точно сформулировал вопрос.
Моя проблема в том, что два клиента приложения ASP.NET могут одновременно попытаться зарегистрироваться под одним и тем же именем.

И мой первый вопрос был:
Как предотвратить возникновение исключения при попытке нарушения ограничения уникальности вследствии одновременного добавления записей двумя клиентами?

Или твой универсальный способ не приводит к исключению в случае попытки добавить запись нарушающую ограничение уникальности?

Здравствуйте, igna, Вы писали:

I>Моя проблема в том, что два клиента приложения ASP.NET могут одновременно попытаться зарегистрироваться под одним и тем же именем.
И? Вот здесь я связь с предыдущим вопросом совсем потерял.. Им надо неразрешать под одним и тем же нименем регистрироваться?

I>Или твой универсальный способ не приводит к исключению в случае попытки добавить запись нарушающую ограничение уникальности?
Нет, не приводит, так как ограничение уникальности не нарушается. GUID уникальный по определению и если запись содержит GUID значит и запись уникальна, осталось использовать GUID в качестве идентификатора записи, чтобы небыло неоднозначностей.

I>два клиента приложения ASP.NET могут одновременно попытаться зарегистрироваться под одним и тем же именем

Следует читать: "два клиента приложения ASP.NET могут одновременно попытаться зарегистрировать своих пользователей под одним и тем же именем". Сорри.

Здравствуйте, Merle, Вы писали:

M>Им надо неразрешать под одним и тем же нименем регистрироваться?

Да. Но как?

Два пользователя одновременно захотели зарегистрироваться выбрав себе имя Абвгд.
Первый проверил таблицу зарегистрированных пользователей — имени Абвгд не нашел.
Второй проверил таблицу зарегистрированных пользователей — имени Абвгд не нашел.
Первый добавил пользователя с именем Абвгд.
Второй попытался добавить пользователя с именем Абвгд. OleDbException.

Hello, igna!

i> Прошу прощения, возможно я не точно сформулировал вопрос.
i> Моя проблема в том, что два клиента приложения ASP.NET могут
i> одновременно попытаться зарегистрироваться под одним и тем же именем.

i> И мой первый вопрос был:
i> Как предотвратить возникновение исключения при попытке нарушения
i> ограничения уникальности вследствии одновременного добавления записей
i> двумя клиентами?

Ну пусть будет исключение. Ну и что? Обработали и выдалили сообщение — "Такой юзер уже есть".
А если пердватительно проверять наличие такого юзера то вероятность возникновения такого исключения дико мала. Вряд ли у тебя часто будет одновременное добавление юзеров. Тем более с одинаковыми никами.

Ну а если исключение по каким-то мистическим причинам неприемлимо то можно самому делать синхронизацию. Сделай внутри метода добавления юзера синхронизацию.

Что то вроде этого

void AddUser(string name)
{
    if(UserNotExist(name))
    {
        lock(someSynkObj) 
        {
            if(UserNotExist(name))
            {
                // Тут код по добавлению юзера в БД
             }
        }
    }
}

Способ универсальный

WBR, Igor Evgrafov.

G> Что то вроде этого

G>

 G> void AddUser(string name)
 G> {
 G>     if(UserNotExist(name))
 G>     {
 G>         lock(someSynkObj) 
 G>         {
 G>             if(UserNotExist(name))
 G>             {
 G>                 // Тут код по добавлению юзера в БД
 G>              }
 G>         }
 G>     }
 G> }
 G>

G> Способ универсальный

Правда у меня есть определенные сомнения, что lock (критической секции) будет достаточно. Если нет то заменить lock на другой объект синхронизации. Например mutex.

WBR, Igor Evgrafov.

Здравствуйте, igna, Вы писали:

I>Да. Но как?
Вот с этого и надо было начинать..

В данном случае, как уже сказали, вполне можно перехватывать исключение и выводить сообщение пользователю.
А в общем виде, для СУБД, задача решается, для блокировочников через уровень изоляции Serializable, а для версионников через блокировку таблиц или синхронизацию на внешнем объекте.

Здравствуйте, GarryIV, Вы писали:

GIV>вероятность возникновения такого исключения дико мала

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

GIV>Правда у меня есть определенные сомнения, что lock (критической секции) будет достаточно.

Сомнения видимо оправданые. Я использовал lock(Application) в АSP.NET приложении и мне удавалось получить исключение. Правда для этого я вставлял искусственную задержку между проверкой отсутствия и добавлением пользователя.

GIV>Если нет то заменить lock на другой объект синхронизации. Например mutex.

Спасибо. Попробую.

Здравствуйте, Merle, Вы писали:

M>А в общем виде, для СУБД, задача решается, для блокировочников через уровень изоляции Serializable, а для версионников через блокировку таблиц или синхронизацию на внешнем объекте.

Serializable с Microsoft Access к сожалению не проходит.

Как заблокировать таблицу — хотел бы знать.

lock(Application) (в приложении ASP.NET) по какой-то причине тоже не прошел, GarryIV посоветовал использовать mutex.

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

Hello, igna!

i> Здравствуйте, GarryIV, Вы писали:

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

Внимание обращать надо. Дело не в этом. Не надо боротся за то чтоб не было исключений. Это бессмыслено. Главное их обработать соответствующим образом.

Борьба за отсутствие исключений приведет только к усложнению кода и замедлению работы приложения.

WBR, Igor Evgrafov.

Здравствуйте, igna, Вы писали:

psc>>В случае готовой таблицы избежать этого нельзя, если не блокировать всю таблицу.

I>Как заблокировать таблицу имея ADO.NET и Microsoft Access 2002?

Холостой update:

UPDATE TABLE SET FIELD = FIELD

Не знаю сработает ли такое в Access?