Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Ну, конечно, с этой идеей я все-таки опоздал года эдак на четыре
Ну еще ничего не поздно исправить. АДО, конечно - это уже просто история. Кому сегодня могут быть интересны идеи 96-97 годов?
Ведь ADO.NET впитало не только все лучшее из ADO (в виде обьекта DataReader, обьекта Command), но и создало новый мир из отсоединенныз от сервера рекордсетов - те Датасетов в новой терминологии.

Но на современной платформе эта ИДЕЯ ОПОВЕЩЕНИЯ тоже реализуема. Причем даже не на каком-то OLEDB-провайдере, а даже на NATIVE SQL CLIENT'е. И не думаю, что по масштабируемости это хуже тяжеловесного решения - NotificationServer+ServiceBroker.


Только вот современные CONNECTION имеют только два события InfoMessage и StateChange. По странному стечению обстоятельств они не возникают у меня при тестах при выдаче KILL. Обьект COMMAND имеет единственное событие CommandComplete, которое у меня лично также не возникает при выдаче KILL.
(буду раз если кто-то опровергнет результаты моих тестов).


Но все же, выход есть - надо просто запустить команду асинхронно и подвесить делегат на завершение команды. Без делегата, для тестов подойдет просто опрос:
        SqlConnection1.ConnectionString &= ";Asynchronous Processing=true"
        SqlConnection1.Open()
        Dim result As IAsyncResult = SqlCommand1.BeginExecuteNonQuery()
        While Not result.IsCompleted

        End While
При проведении тестов обратите внимание на одну интересную фишку - вот этот параметр "Asynchronous Processing" дизайнер студии восьмого бейсика не берет и его приходится добавлять вручную.
26 авг 06, 13:15    [3057019]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10821
Блог
Shocker.Pro

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

Хотя может быть под состоянием ожидания подразумевается, например, ожидание поступления данных из дисковой подсистемы во время выполнения, скажем, сканирования индексов... То есть выборка-то выполняется, но в конкретный момент не требует ресурсов процессора. Тогда понятно, о чем речь. Тогда получается, что запрос с мощными формульными расчетами может существенно затормозить выполнение других запросов.


Ага... если поток ждёт дисковые операции, в это время планировщик запускает следующий поток на исполнение своему процессору, выбирая поток из списка ожидающих исполнения потоков.
26 авг 06, 13:15    [3057021]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Зачем рвать/устанавливать соединение, когда проще ждать разблокировки , например, таблички или даже строки в табличке в той же самой асинхронной процедуре
Хм...У Алекса просто нюх какой-то на хорошие идеи. На современной платформе (судя по моим тестам) разрыв соединения вообще ни к каким событиям не приводит.
Не знаю почему. Опровергните кто может это утверждение...
Те ловить событие надо все равно в обьекте Command. А ничего лучше блокировки/разблокировки - отборы с хинтом with (NOLOCK) - для этого просто не придумаешь...
26 авг 06, 13:39    [3057041]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Если уж нет желания иcпользовать стандартные средства доставки сообщений типа MSMQ и Notification Service, а также не волнует наличие второго постоянного соединения, то я бы лучше использовал расширенные ХП, чем KILL.
Вот пример CLR процедур для SQL2005, вводящих соединение в ожидание события с использованием объектов синхронизации. Клиент подписывается на именованные события, которые хочет получать. При возникновении события, ожидающим клиентам возвращается его имя. Можно ожидать не все подписанные события, а какое то определенное. В аттаче уже собранная DLL.
То же самое легко можно сделать и для SQL2000.

public class CLRQueue
{
    //private static EventWaitHandle ewh = new EventWaitHandle(false, EventResetMode.ManualReset);

    // define named events
    private static Dictionary<string, EventWaitHandle> dicEvent = new Dictionary<string, EventWaitHandle>();
    // define subscribe event for each spid
    private static Dictionary<int, ArrayList> dicSubscribeEvent = new Dictionary<int, ArrayList>();

    // subscribe to event
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static SqlInt32 SubscribeEvent(Int32 spid, string EventName)
    {
        EventWaitHandle ewh;
        ArrayList arrHandle;

        // critical section
        Monitor.Enter(dicSubscribeEvent);

        // find exists event or create it
        if (!dicEvent.TryGetValue(EventName, out ewh))
        {
            ewh = new EventWaitHandle(false, EventResetMode.ManualReset);

            // save event
            dicEvent.Add(EventName, ewh);
        }

        Monitor.Exit(dicSubscribeEvent);
        // end critical section

        // load already subscribed event for spid 
        if (!dicSubscribeEvent.TryGetValue(spid, out arrHandle))
        {
            arrHandle = new ArrayList();
            dicSubscribeEvent.Add(spid, arrHandle);
        }
        
        if (!arrHandle.Contains(ewh))
        {
            arrHandle.Add(ewh);
            return 0;
        }

        return -1;
    }

    // drop subscribe to event
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static SqlInt32 RejectEvent(Int32 spid, string EventName)
    {
        EventWaitHandle ewh;
        ArrayList arrHandle;

        if (dicEvent.TryGetValue(EventName, out ewh))
        {
            if (dicSubscribeEvent.TryGetValue(spid, out arrHandle))
            {
                if (arrHandle.Contains(ewh))
                {
                    arrHandle.Remove(ewh);
                    return 0;
                }
            }            
        }

        return -1;
    }

    // wait for passed event or wait for any subscribe event, if NULL
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static SqlInt32 WaitEvent(Int32 spid, string EventName, out string SignaledEvent)
    {
        SignaledEvent = null;

        if (EventName == null)
        {
            ArrayList arrHandle;

            if (dicSubscribeEvent.TryGetValue(spid, out arrHandle) && arrHandle.Count > 0)
            {
                EventWaitHandle[] ewh = (EventWaitHandle[])arrHandle.ToArray(typeof(EventWaitHandle));                

                Int32 iEvent;
                iEvent = EventWaitHandle.WaitAny(ewh);

                
                if (iEvent>=0) // define name of signaled event
                {
                    foreach (KeyValuePair<string, EventWaitHandle> kvp in dicEvent)
                    {
                        if (kvp.Value.Equals(ewh[iEvent]))
                        {
                            SignaledEvent = kvp.Key;
                        }
                        
                    }
                }                

                return iEvent; // return number of signaled event
                
            }
        }
        else
        {
            EventWaitHandle ewh;

            if (dicEvent.TryGetValue(EventName, out ewh))
            {
                ewh.WaitOne();
                SignaledEvent = EventName;

                return 0;
            }            
        }

        return -1;
    }

    // Signal event and unblock all waiting thread
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static SqlInt32 SignalEvent(string EventName)
    {
        EventWaitHandle ewh;
        Int32 iRetCode = -1;

        Monitor.Enter(dicEvent);

        if (dicEvent.TryGetValue(EventName, out ewh))
        {
            ewh.Set(); // signal all block threads
            ewh.Reset();
            iRetCode = 0;
        }

        Monitor.Exit(dicEvent);
     
        return iRetCode;
    }
}

Регистрация в БД
declare @dbname sysname
set @dbname = db_name()

exec('alter database '+@dbname+' set trustworthy on')
go

create assembly CLRFunc
from 'C:\Develop\Projects\VC#\SqlCLRFunction\SqlCLRFunction\bin\Debug\SqlCLRFunction.dll'
with permission_set=unsafe
go

drop procedure CLRWaitEvent
go
create procedure CLRWaitEvent(@spid int, @event nvarchar(128)=null, @SignaledEvent nvarchar(128) = null output)
as external name CLRFunc.CLRQueue.WaitEvent
go

drop proc CLRSignalEvent 
go
create proc CLRSignalEvent(@event nvarchar(128))
as external name CLRFunc.CLRQueue.SignalEvent
go

drop proc CLRSubscribeEvent 
go
create proc CLRSubscribeEvent(@spid int, @event nvarchar(128))
as external name CLRFunc.CLRQueue.SubscribeEvent
go

drop proc CLRRejectEvent 
go
create proc CLRRejectEvent(@spid int, @event nvarchar(128))
as external name CLRFunc.CLRQueue.RejectEvent
go

Пример использования:
1 коннект (ожидающий)
declare @result int, @SignalEvent sysname

exec @result = CLRSubscribeEvent @@spid, 'Event1' 
exec @result = CLRSubscribeEvent @@spid, 'Event2' 
exec @result = CLRSubscribeEvent @@spid, 'Event3' 

-- ждем любое событие, на которые подписаны
exec @result = CLRWaitEvent @@spid, null, @signalevent output 
select @result, @signalevent

-- ждем заданное событие
exec @result = CLRWaitEvent @@spid, 'Event2', @signalevent output 
select @result, @signalevent

2 коннект (сигнализирующий)
declare @result int

-- посылаем события
exec @result = CLRSignalEvent 'Event3'
select @result

exec @result = CLRSignalEvent 'Event2'
select @result


К сообщению приложен файл (SqlCLRFunction.dll - 20Kb) cкачать
26 авг 06, 13:54    [3057062]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22576
WiRuc
вводящих соединение в ожидание события с использованием объектов синхронизации. Клиент подписывается на именованные события, которые хочет получать. При возникновении события, ожидающим клиентам возвращается его имя.


Ну этот вариант - практически один в один как у Уфимцева, только реализованный на CLR
26 авг 06, 14:04    [3057073]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Shocker.Pro
Ну этот вариант - практически один в один как у Уфимцева, только реализованный на CLR

Возвможно, его решение я не видел. Но чем юзать административную комманду KILL, имеющую ограничения на использование, лучше уж такой подход.
26 авг 06, 14:09    [3057083]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
то я бы лучше использовал расширенные ХП, чем KILL
Я сторонник самого активного применения сборок вместо протягивания своих мыслей через игольное ушко замороченного-презамороченного компилятора. Однако...
вы не находите, что в данном случае это достаточно громоздкое решение и простой отбор с хинтом NOLOCK будет ГОРАЗДО КРАСИВЕЕ?
26 авг 06, 14:11    [3057084]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
разрыв соединения вообще ни к каким событиям не приводит
Я немного поправлюсь. Ни к каким событиям обьектов Connection или Command за исключением события завершения асинхронной команды.
26 авг 06, 14:31    [3057109]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22576
WiRuc
Возвможно, его решение я не видел. Но чем юзать административную комманду KILL, имеющую ограничения на использование, лучше уж такой подход.


Ссылка в самом первом моем посте в этой ветке.

Все зависит от контекста. Я готов дать права процессадмина нужному процессу, но работая на SQL2000 придется либо регистрировать расширенную ХП, либо работать с СОМ через sp_OA. А я-то как раз предложил решение стандартными средствами.

Полагаю, если для кого-то это УЖЕ не представляет практического интереса (из-за появления SQL2005), то по крайней мере академический. По крайней мере, я получил большое удовольствие от простого решения проблемы, которая возникла еще год назад, когда SQL2005 все же не был так изучен и распространен... Ну и от общения в этой ветке тоже, так что еще раз выражаю всем благодарность за проявленный интерес. :)
26 авг 06, 14:40    [3057122]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
sysadm2000
вы не находите, что в данном случае это достаточно громоздкое решение и простой отбор с хинтом NOLOCK будет ГОРАЗДО КРАСИВЕЕ?

Не понял сути решения с использованием блокировок, опишите подробней.
26 авг 06, 15:09    [3057161]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Не понял сути решения с использованием блокировок, опишите подробней.
Ну это описание лишь схемы - ясно что можно нафаршировать эту схему логикой. Однако эта схема:
1. Позволяет полностью избавиться от KILL, что основная проблема в схеме, предложенной автором топика.
2. Гораздо-гораздо-гораздо массштабируема, ибо не требует такой поистине ДОРОГОСТОЯЩЕЙ операции, как установка/разрыв соединения.
3. Наиболее существенным плюсом этой схемы, относительно идей автора топика, я считаю то обстоятельство, что это будет работать и с ADO.NET, а не только с ADO.
4.Ну относительно ваших идей со сборкой - я свое мнение уже высказал выше.
Наконец, надо заметить, что эту идею (оппонируя автору топика) предложил Aleks, я ее только просто увидел.


Так вот, создаем заблокированный ресурс - ну собственно как угодно, да хоть вот так:
begin transaction one
select * from link with (holdlock)
waitfor delay '00:01:00'
commit
Ну ясный пень, я таблу взял просто для демонстрации, фактически можно работать даже без таблы, а просто по именованной транзакции.
Но это более сложная техника, я ее тут не буду описывать.
После создания заблокированного ресурса - наслаждаемся списком заблокированных ресурсов:
exec sp_lock
и наконец, АСИНХРОННО из клиента выдаем:
Insert  link  default values
Ну, на самом деле, конечно, в зависимости от установок может потребоваться
Insert  link with (holdlock) default values
- я думаю, вы понимаете это и я не заостряю на этом внимание.

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

Логика подписки реализуется в данных таблы link, которая собственно и возвращается клиенту после возникновения события.
26 авг 06, 16:07    [3057237]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22576
sysadm2000
begin transaction one
select * from link with (holdlock)
waitfor delay '00:01:00'
commit


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

Кроме того, блокировку на таблицу вешает ОДИН процесс. а освободить блокировку должен ДРУГОЙ процесс. Какие права должны быть у этогго второго процесса?

Т.е., когда начинаешь вдаваться в детали, решение ИМХО становится тяжеловесным, хотя, его достоинства я уже упоминал.
26 авг 06, 17:01    [3057307]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
sysadm2000
Техника освобождения ресурсов стандартная - их множество разных - это не суть вопроса.

Именно это меня и интересует - как вы собираетесь особождать блокировку, наложенную в другом коннекте? С помощью блокировок, как обычных, так и уровня приложения, нельзя организовать оповещение клиентов.
26 авг 06, 17:02    [3057309]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
ChA
Member

Откуда: Москва
Сообщений: 11373
Shocker.Pro
Других способов не просто вагон, но еще и маленькая тележка, но они заведомо будут проигрывать Вашему варианту просто потому, что это Вы его придумали. Здесь Вы, в первую очередь, доказываете его плюсы и подчеркивате минусы других методов. IMHO, это неконструктивно, и, более того, многие аргументы выглядят не очень убедительно.
Возможно, стоит написать статью, с примерами, типа, "Еще один способ доставки уведомлений", и потревожить А.Гладченко, на предмет включения ее в рассылку. Для FAQ, опять же - IMHO, эта тема не очень годится, так как способов уведомления слишком много, чтобы игнорировать их, в угоду одного единственного. Лучше тогда сделать обзорную статью, как, например, статья по логгированию изменений уважаемой GreenSunrise.

С уважением.
26 авг 06, 17:25    [3057332]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22576
ChA
Здесь Вы, в первую очередь, доказываете его плюсы и подчеркивате минусы других методов.


Ну да. Минусы своего метода я написал в самом первом посте. А подчеркивать чужие минусы - лучший способ поддержать дискуссию. которая лично мне интересна :) :) :)

ChA
Возможно, стоит написать статью, с примерами, типа, "Еще один способ доставки уведомлений", и потревожить А.Гладченко, на предмет включения ее в рассылку. Для FAQ, опять же - IMHO, эта тема не очень годится, так как способов уведомления слишком много, чтобы игнорировать их, в угоду одного единственного.


Согласен. И с Вашим названием тоже. Гладченко, предложил написать мне эту статью еще на первой странице топика, что очень мне польстило, я сам даже и не претендовал. Но вот обзорную статью я пожалуй не потяну. Впрочем, полагаю, эта ветка представляет собой уже достаточный материал, для тех, кто заинтересуется вопросом, я не ожидал, что дискуссия будет такой разнообразной. Как раз в FAQ можно тупо разместить ссылку за эту ветку с комментарием "а здесь можно найти множесто различных методов...", а дальше человек найдет себе что-нибудь по вкусу.
26 авг 06, 17:43    [3057361]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Да, но простите - это опять получается опрос. В данном случае постоянно будет опрашиваться почтовый сервер.
Я немного знаком с тематикой программирования для Exchange - ну по крайней мере писал дефрагментацию почтового хранилища. Так вот там в принципе есть две темы программирования - одна ФИЛЬТРАЦИЯ данных со спамом, а вторая УВЕДОМЛЕНИЕ о поступлении писем. До эпохи исторического материализма эта задача решалась вызовом COM+, после - NetRemoting. Те никаким опросом при уведомлениях по SQL-MAIL и не пахнет - ну по крайней мере при наличии Exchange, с техникой работы в других почтовиках я не знаком.


Еще. При наличии уведомления с помощью разрыва соединения - мы имеем только "Здрасте, err.Number=-2147467259", а вот при уведомлении с помощью обьекта COMMAND, подвешенного на заблокированном ресурсе
Insert  link  default values
select * from link where...
МЫ ИМЕЕМ ОСМЫСЛЕННЫЙ РЕКОРДСЕТ. Те кто, кого и о чем именно уведомляет.


На каждого подключенного клиента придется создать по таблице
Да на здоровье - таблицы типа #. Хотя я хотел бы подчеркнуть, что для техники на основе блокировки, ГОДИТСЯ ЛЮБОЙ ОБЬЕКТ, ПОИМЕНОВАННЫЙ В ТАБЛИЦЕ SYSLOCK сервера. Ибо для элементов таблицы SYSLOCK уже внутри SQL-сервера реализован межпроцессорынй механизм уведомлений, а асинхронная команда, подвешенная на ожидании освобождения ресурса из SYSLOCK - просто асинхронно поднимает это событие из ядра SQL-сервера на клиента.


как вы собираетесь особождать блокировку, наложенную в другом коннекте
Ну например, способом предложенным автором топика - KILL. Хотя для того, чтобы грохнуть ОДНУ транзакцию, не обязательно убивать весь процесс. Тема уничтожения именованной транзакции - это отдельная тема. Можно провести эксперименты по прямому изменению таблы SYSLOCK, а потом еще раз обратиться к API-блокировки/разблокировки. Несколько раз встречал хорошие рецепты по выполнению этого из сборок. Знаю, что есть специфика уничтожения транзакций в среде MSDTS. Важно, что это проблема решаемая. Я думаю, что в контексте получения уведомлений от сервера - одного способа достаточно.
26 авг 06, 19:05    [3057487]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
уважаемой GreenSunrise
Не понял - GreenSunrise женщина???????
26 авг 06, 19:08    [3057491]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10821
Блог
И всётаки, все методы с использованием waitfor delay 'bla:bla:bla' мне, как DBA, не нравятся.

Мне больше импонирует стандартное средство в Юконе, которое задействует брокер и не нуждается в дополнительной поддержки службы Nitification Service, разве только если необходимо будет реализовать совсем уж экзотические способы и средства доставки с подпиской через WEB или получением дайджестов...

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

В общем, из штатных средств, остаётся только NS (со всеми его недостатками), если речь о 2000-м, или уведомления ADO.NET вкупе с брокером в Юконе...
26 авг 06, 19:21    [3057528]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Мне больше импонирует стандартное средство в Юконе
А вот я с вами не соглашусь. Здесь я положил два примера уведомлений на основе событий в обьектах Command и на событиях в обьекте Connection. Для ADO и ADO.NET. У меня есть задел проги оповещения по MSMQ. Я некоторое время работал почтовым админом и видел реальную эксплуатацию (чужих, не моих) прог уведомления из SQL-MAIL. И наконец, у меня есть личный, написанный мною еще на VB7, а потом переписанный на VB8 прокси-сервер уведомлений по TCP/IP, который сейчас находится в промышленной эксплуатации.
Это все я сказал для того, чтобы стало ясно, что тема уведомлений об изменения в рекордсетах мне ОЧЕНЬ БЛИЗКА и трогает меня за живое. И мое заключение по поводу NS+SB - очень отстойно и тяжеловесно. Из пушки по воробьям. Нарушается самый элементарный закон программирования - не создавайте сущностей без необходимости. А в этом решении столько создано ЛИШНЕГО (в стремлении микрософта удовлетворить ВСЕХ) - что изящество решения просто ПОТЕРЯЛОСЬ.
То самое изящество, которое присутсвует в предложении автора топика (ну если он конечно учтет все замечания, в первую очередь выстказанное мною выше об отлове события на в обьекта Connection, а в обьекте Command, ну а во вторую очередь все-таки не просто тупо рвать коннект, а давать запрос на заблокированный ресурс).
26 авг 06, 19:37    [3057551]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Shocker.Pro
Member

Откуда: ->|<- :адуктО
Сообщений: 22576
sysadm2000
в первую очередь выстказанное мною выше об отлове события на в обьекта Connection, а в обьекте Command


Маленькое техническое замечание, не сочтите за придирку - у объекта Command в ADO просто нет событий.
26 авг 06, 20:23    [3057616]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10821
Блог
sysadm2000

А вот я с вами не соглашусь. Здесь я положил два примера уведомлений на основе событий в обьектах Command и на событиях в обьекте Connection. Для ADO и ADO.NET. У меня есть задел проги оповещения по MSMQ. Я некоторое время работал почтовым админом и видел реальную эксплуатацию (чужих, не моих) прог уведомления из SQL-MAIL. И наконец, у меня есть личный, написанный мною еще на VB7, а потом переписанный на VB8 прокси-сервер уведомлений по TCP/IP, который сейчас находится в промышленной эксплуатации.


Я, быть может, возьму свои слова обратно по поводу использования сборки, если мне раскажут, как работает CLRWaitEvent ;)
Решение с очередью MSMQ мне нравится (концептуально) :) Надеюсь, MSMQ стал работать стабильнее, чем раньше...

sysadm2000

Это все я сказал для того, чтобы стало ясно, что тема уведомлений об изменения в рекордсетах мне ОЧЕНЬ БЛИЗКА и трогает меня за живое. И мое заключение по поводу NS+SB - очень отстойно и тяжеловесно. Из пушки по воробьям. Нарушается самый элементарный закон программирования - не создавайте сущностей без необходимости. А в этом решении столько создано ЛИШНЕГО (в стремлении микрософта удовлетворить ВСЕХ) - что изящество решения просто ПОТЕРЯЛОСЬ.


Я уже порывался было ответить по поводу NS+SB (разделяя полностью Ваше мнение об этой связке), что в Юконе вместе их использовать совсем не обязательно... Дело в том, что Брокер - это замена MSMQ, его одного вполне достаточно для организации очередей и оповещений и совсем не обязательно использовать такие монстрообразные средства доставки, как NS. (Алексей Шуленин на Платформе 2006 показывал пример оповещений об изменении данных, который он писал прямо на глазах у аудитории и это заняло у него минут 5, не больше) (Он использовал (насколько я помню) только брокера, и оповещал обычное клиентское приложение, тут же собранное)...
Для SQL 2000 NS использовать можно (вот только нужно ли?), но я бы предпочёл завязываться только на MSMQ.
26 авг 06, 20:25    [3057618]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Александр Гладченко
Я, быть может, возьму свои слова обратно по поводу использования сборки, если мне раскажут, как работает CLRWaitEvent ;)

А что именно объяснить?
26 авг 06, 20:47    [3057654]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
WiRuc
Member

Откуда: Воронеж
Сообщений: 1280
Я этот пример тоже писал на коленке и заняло это конечно не 5 минут, но тоже достаточно мало времени.
26 авг 06, 20:48    [3057657]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
если мне раскажут, как работает CLRWaitEvent 
Тоже кстати, великолепное решение. Просто на голову выше микрософтовских монстров. Написано оно на стандартных .NET-способах синхронизации потоков из раздела System.Threading. Сборка - это экземпляр статического класса, как модуль в приципе. Те коллекции-словари dicEvent и dicSubscribeEvent существуют всегда и никуда не деваются от вызова к вызову.
Ну а дальше какие проблемы - приняли текстовое имя ресурса, добавили его в коллекцию коллекцию, есть методика синхронизации потоков...
При вызове WaitEvent вызывающий процесс зависает внутри функции по .WaitAny.
Ну тут всякие проверки - это уже дело техники. Каждый программер их делает по своему, я например никогда не использую Dictionary, а делаю типизированные спецколлекции, ну например вот как в моем прокси-сервере ОПОВЕЩЕНИЙ:

К сообщению приложен файл. Размер - 0Kb
26 авг 06, 21:24    [3057715]     Ответить | Цитировать Сообщить модератору
 Re: Уведомление клиента о событии на SQL-сервере! НОВОЕ РЕШЕНИЕ!  [new]
sysadm2000
Member

Откуда: Москва
Сообщений: 1212
Все надо завязывать обсуждать эту тему (по крайней мере мне) - а то пошел просто треп...
26 авг 06, 21:38    [3057727]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить