Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Возникла необходимость в хранимой процедуре получить список подключенных пользователей (в виде рекордсета, чтоб потом по нему курсором пробежаться). Как? Или, альтернативный вариант - при подключении пользователя присвоить его коннекту какой-то GUID и в дальнейшем иметь возможность из других коннектов проверять - жив пользователь с этим гуидом или уже отвалился. Суть того что мне в конечном итоге нужно: при открытии пользователем документа в базе нужно в какую-то таблицу положить идентификатор пользователя и идентификатор документа, при закрытии - запись стереть. Другой пользователь, если в этой таблице есть идентификатор документа и создалась она не в его коннекте - получает отлуп или выполняется какое-то действие. При попытке открыть документ, если в этой таблице присутствует запись а пользователь зафиксированный в этой записи отвалился - запись грохнуть и документ разблокировать. То есть поведение примерно аналогичное как при параллельном открытии документов в хранилище MS Exchange :) Стандартный механизм блокировок не катит - и структура документа сложная, и трехслойка планируется. Надеюсь понятно написал :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 13:51 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
список вроде так можно получить Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 15:33 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Список пользователей не нужен, все в ASA делается гораздо проще. 1. Делаем таблицу хранения логических блокировок: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 2. Делаем процедуру добавления/снятия блокировки: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 3. Вызываем блокировку и разблокировку документов где нужно, указывая имя таблицы и код записи: Код: plaintext 1. 2. 3. 4. 4. Создаем событие на отключение пользователя, чтобы потереть его блокировки, которые он не успел снять (в случае экстренного отключения сессии): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Вуаля, система логических блокировок готова, другие РСУБД могут кусать локти ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 16:36 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
ASCRUS спасибо огромное! А можно предусмотреть ситуацию, когда два юзера зашли под одним логином? то есть существует ли какой-то глобальный идентификатор коннекта в базе, который можно поюзать внутри процедуры? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 17:02 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Наверное нужно использовать EVENT_PARAMETER ('') ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 17:31 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
сори, выпало :( EVENT_PARAMETER('ConnectionID') ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 17:32 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Рыжий Котсори, выпало :( EVENT_PARAMETER('ConnectionID') Угу, в таблице сделать тип еще Connect_id unsigned int, в процедуре вместо User_Name и CURRENT USER писать Connect_id и CONNECTION_PROPERTY('Number'), в событии соотвествующе Connect_id и EVENT_PARAMETER('ConnectionID'). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 17:37 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Полный, по идее работоспособный скрипт для FAQ: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 18:32 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Огромное спасибо за помощь. Уже и сделал, и внедрил :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 18:43 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Vladimir KozlovОгромное спасибо за помощь. Уже и сделал, и внедрил :) Чем ASA и радует - если знаешь, то чуть кода, все работает и никакого геммороя, плясок с бубнами или прикручивания кода со стороны клиента. Кстати советую обратить внимание на один ньюанс - я не зря ввел в процедуру параметр AutoCommit, по идее лучше всего этот флаг не выставлять, т.е. чтобы само клиентское приложение явно завершало транзакцию. Это гарантирует, что если во время получения или сохранения данных произойдет ошибка, то не получится, что блокировка к примеру осталась висеть, а SELECT не отработал и клиент ничего не получил. Логика на клиенте должна быть такая (есественно никаких AutoCommit на клиенте): 1. Вызываем процедуру для блокировки документа 2. Возвращаем данные на клиента 3. Если все успешно, то COMMIT, иначе ROLLBACK и выход 4. Редактирование документа 5. Сохранение документа 6. Если не успешно, то ROLLBACK и возврат на пункт 4 7. Вызываем процедуру для разблокировки документа 8. Если все успешно, то COMMIT, иначе ROLLBACK и возврат на пункт 4 Далее для пункта 7 стоит учесть один существенный момент - если на время редактирования документа сессия отвалится, то естественно блокировка с документа снимется и пункт 8 вызовет ошибку, что в принципе правильно, так как даже если сессия обратно и соединится на момент сохранения данных, то у нее уже будет другой идентификатор и нет гарантии, что за момент отвала сессии, другой пользователь уже не отредактировал или сейчас редактирует данный документ. Соотвествующе, по хорошему, как не будет обидно пользователю, разрешить ему уже сохранение документа в таком случае нельзя, он может только отменить изменения и заново открыть для изменения документ. Однако есть решение данной проблемы: для пункта 7 при вызове процедуры можно выставить флаг @RaisError в ноль и таким образом после пересоединения сессии, он все таки сможет удачно пересохранить документ, так как в процедуре не будет возбуждена ошибка. Здесь, чтобы исключить ситуацию неявной перезаписи измененного уже другим пользователем документа на время отвала сессии, необходимо в изменяемую таблицу самого документа добавить поле LastTime TIMESTAMP с DEFAULT TIMESTAMP и считывать его тоже на редактирование, а при сохранении документа проверять по этому полю: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 19:05 |
|
||
|
ASA: получить список подключенных юзеров
|
|||
|---|---|---|---|
|
#18+
Ну и уж как последний штрих - если вдруг не дай бог клиент получает долго или много данных, то, чтобы другие клиентские приложения при попытке открыть этот же документ не ждали, пока первый клиент все получит, в процедуре лучше в запрос проверки на блокировку документа поставить хинт грязного чтения (вот где оно и пригодилось): Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.01.2006, 19:14 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=33477466&tid=2013138]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
67ms |
get topic data: |
14ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
2ms |
| others: | 253ms |
| total: | 449ms |

| 0 / 0 |
