C # sql instancing, возможно ли перечислить все соединения sql, не утилизируемые в контексте экземпляра объекта?

Question

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

по сути, у меня есть N-уровневая прикладная среда, которая делает вызов«провайдер данных», который, в свою очередь, обращается к базе данных SQl.

Я хочу сказать провайдеру данных «показать мне все соединения, которые были использованы, но еще не утилизированы», поэтому я могу, если потребуется, принудительноудаление "любых соединений, которые не должны быть открыты.

Если я не могу сделать это в C #, есть ли какая-нибудь альтернатива на сервере Sql, которая позволяет мне понять, что происходит?

РЕДАКТИРОВАТЬ:

Скорее всего, этот экземпляр кода вызывался из любого места в приложении на основе экземпляра бизнес-объекта, который вызывает одно местоположение на уровне API.Уровень API предоставляет интерфейс, для которого он вызывает методы.

Я надеялся, что либо объект, реализующий интерфейс, либо уровень API, посмотрят на стек вызовов и решат погоду ждать, выдать исключение или сделать вызов (открыть новое соединение).

Проблема, которую я обнаружил, заключалась в том, что у меня был такой бизнес-объект, как, скажем, «персона», у которого было свойство, называемое «транспортное средство», и это был объект типа транспортного средства, который содержал свойство, называемое «владелец», что, конечно, отсылало кродительский объект.

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

Таким образом, исправление было достаточно простым... ленивая загрузка по крайней мере 1 из 2 уровней или вообще удаление циклической ссылки.

Однако я все же хотел бы взглянуть на мой стек вызовов во время выполнения и задать вопрос ... это вызоветпроблема, если я пытаюсь создать экземпляр этого бизнес-объекта?

Это заставило меня задуматься о кешированиимы реализовали его в слое API позже) ... если бы это было так, проблема слишком большого количества соединений исчезла, но была заменена на гораздо более серьезную проблему "я собираюсь разобрать весь свой оперативный памяти".

Итак, я подумал ... почему я не могу проанализировать стек вызовов?

Ответ ...

Мне бы не пришлось, если я пишу хороший код... но я все еще хочу:)

Answer 1

Не знаю о C #, но в Sql Server вы можете использовать эти запросы для мониторинга открытых соединений:

1.Получить список баз данных и количество соединений

SELECT 
    DB_NAME(dbid) as DBName, 
    COUNT(dbid) as NumberOfConnections,
    loginame as LoginName
FROM
    sys.sysprocesses
WHERE 
    dbid > 0
GROUP BY 
    dbid, loginame

2.Получить все подключения для пользователя - sp_who 'userName'

3.Получить информацию для подключения DBCC INPUTBUFFER(1)

Answer 2

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

Кто владеет ресурсом, ответственен за освобождениеэто. Поэтому я предлагаю сосредоточиться на выпуске ресурса в классе, которому он принадлежит.

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

Если вам действительно нужно это сделать , ничто не мешает вам вручную зарегистрировать соединение в центральном реестре, когда оно открывается, и отменить регистрацию, когда оно закрыто.Это может быть реализовано как шаблон синглтона, но, как я уже сказал, я советую против этого.

Answer 3

Проверка циклических ссылок для предотвращения сумасшедших ошибок:)

Не задавайте глупых вопросов, которые ожидают, что Microsoft разрешит "проверку плохого кода" во время выполнения.