|
|
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
Как сделать локирование таблицы только для INSERT операций? Ну, то есть чтобы INSERT от разных пользоватеелей выстраивались в очередь (таблица на инсерт-операции становиться однопользовательской). Напрашиваеться LOCK TABLE IN EXCLUSIVE MODE, но, думаю, не есть Гуд локирование всей таблицы для удаления и апдейта только ради инсертов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2002, 13:47 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
а за чем? все равно остальные увидят, вставленные данные только после commit'а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.03.2002, 15:23 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
Вот именно что после коммита. Будем это считать не корректно заданным вопросом, тогда задам пространнее: Как сделать, чтобы от различных пользователей дынные не дублировались. Вычистка таблицы после инсертов не устраивает. Поэтому удобно проверку сделать на инсерт-триггере (если уже такая запись есть например в 5 последних записях - выхожу из триггера исключением). Но тогда и инсерты должны работать строго последовательно, но ни как не параллельно, иначе алгоритм не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2002, 08:37 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
А не проще создать уникальный индекс на нужные поля и делать commit поскорее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2002, 10:16 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
Лучший метод в таких ситуациях, по-моему, это изменить алгоритм работы так, чтобы подобных ситуаций небыло. А как метод решения можно предложить следующее: пытаешься заблокировать таблицу целиком, если успешно, разблокируешь и вставляешь данные, иначе кто-то уже вставляет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.03.2002, 12:02 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
to nick: Полная ерунда, "пытаешься заблокировать таблицу целиком, если успешно, разблокируешь и вставляешь данные, иначе кто-то уже вставляет" - ясно, что это ничего ничего не даст. Ну чтож, LOCK TABLE, так LOCK TABLE. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2002, 09:29 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
это даст возможность другому изменять данные, а если ты заблокируешь, то ничего кроме просмотра данных другим делать будет нельзя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2002, 09:39 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
Так задача то в том, чтобы исключить возможность вставки дублированных записей. Ваше предложение это проблему не рашает. Вот и все. Если не верите, специально открою какой-нибудь фотошоп и нарисую для вас тайм-диаграмму с локами, коммитами, инсертами и прочее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2002, 10:43 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
я это и сам могу нарисовать просто вопрос стоял про insert, я и исходил что блокировка нужна только для insert "не есть Гуд локирование всей таблицы для удаления и апдейта только ради _инсертов_." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2002, 11:57 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
2 none Если проблема в исключении возможности вставки дублированных записей - то почему она не может быть решена, введением необходимых ограничений на уникальность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2002, 15:06 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
Потому, что создать уникальный индекс на несколько полей - самое простое решение. Но мы не ищем легких путей! А что за собой повлечет такая мера, никово не заботит? Например размер этого индекса. Пусть мне нужно прослеживать уникальность в таблице с ID NUMBER(10) и например с 5 полями VARCHAR2(4000) и остальной чепухой. Прикидываете размер индекса при 1 тысячи записей, 5, 10, 100? А время UPDATE такого индекса? Нет, не согласен с таким решением. Ладно, вопрос снимаю. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2002, 08:09 |
|
||
|
Table LOCK FOR INSERT
|
|||
|---|---|---|---|
|
#18+
Так бы сказал, что извратится хочешь. Тебе действительно нужно проверять уникальность по ВСЕМ полям в таблице с ID NUMBER(10) и например с 5 полями VARCHAR2(4000)? ID, например, и так уникальный по определению (да и индекс на нём и так будет свой). А может просто кривая структура БД? С проверкой на инсерт-триггере таблицы у вас так-же будут проблемы - вы нарвётесь на ORA-04091. Придётся делать контроль уникальности на стороне клиента - а это тоже потенциальный геморрой. Судя по вашему количеству записей "1 тысячи записей, 5, 10, 100" это не крутая OLTP-система где можно было-бы беспокоится о времени UPDATE (тем более что в вашем случае и при UPDATE тоже нужна будет проверка уникальности). Да и размер индекса на это количество записей - копейки. Удивительно, что вас это заботит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2002, 12:00 |
|
||
|
|
start [/forum/topic.php?fid=52&msg=32024682&tid=1993422]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 16ms |
| total: | 151ms |
| 0 / 0 |
