Всем привет!
Для работы с БД использую BlToolKit. Когда в системе один пользователь — всё работает как часы, когда, например, 6 — начинаются валиться ошибки, причём всякие.
Подскажите как правильно организовать многопоточную работу приложения с БД, использующего BlToolKit.
Здравствуйте, barcik, Вы писали:
B>Для работы с БД использую BlToolKit. Когда в системе один пользователь — всё работает как часы, когда, например, 6 — начинаются валиться ошибки, причём всякие. B>Подскажите как правильно организовать многопоточную работу приложения с БД, использующего BlToolKit.
Прежде всего проверить не кешировать самому открытые соединения к базе. Т.е. DbManager должен создаваться при каждом запросе и в конце диспозиться. Создавать и сохранять его на будущее нельзя.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Прежде всего проверить не кешировать самому открытые соединения к базе. Т.е. DbManager должен создаваться при каждом запросе и в конце диспозиться. Создавать и сохранять его на будущее нельзя.
1)DbManager должен быть SingleTon-ом?
2) Нужно ли ставить блокировки при выполнении запроса например:
lock (locker)
{
al = manager.DBManager.SetSpCommand("GET_GROUPS",
manager.DBManager.Parameter("P_UID", userId)
).ExecuteList(typeof(GroupBE));
}
где manager.DBManager — это объект класса DbManager.
Здравствуйте, barcik, Вы писали:
B>1)DbManager должен быть SingleTon-ом? B>2) Нужно ли ставить блокировки при выполнении запроса например:
Нет, ничего этого не надо. DbManager надо создавать только на момент выполнения транзакции.
using (DbManager db = new DbManager()
{
// ...
}
В общем-то, это классика ADO.NET. Объекты DbConnection, рапером над которыми является DbManager, не должны кешироваться приложением. ADO.NET поддерживает пул соединений и делает это значительно лучше и эффективней, чем может сделать прикладной программист.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Прежде всего проверить не кешировать самому открытые соединения к базе. Т.е. DbManager должен создаваться при каждом запросе и в конце диспозиться. Создавать и сохранять его на будущее нельзя.
Есть некоторая проблема с Dispose. Если его не вызывать то, все в итоге падает в финализаторе. Можно ли с этим что-то сделать?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
IT>>Прежде всего проверить не кешировать самому открытые соединения к базе. Т.е. DbManager должен создаваться при каждом запросе и в конце диспозиться. Создавать и сохранять его на будущее нельзя.
TK>Есть некоторая проблема с Dispose. Если его не вызывать то, все в итоге падает в финализаторе. Можно ли с этим что-то сделать?
Как именно падает? С исключением? Можно примерчик?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Как именно падает? С исключением? Можно примерчик?
Всяко бывает. Оракловый провайдер, непример, падает, если сначала Connection закрыть, а потом IDataReader, открытый из этого соединения.
Только к булкиту это отношения не имеет.
Здравствуйте, IT, Вы писали:
TK>>Есть некоторая проблема с Dispose. Если его не вызывать то, все в итоге падает в финализаторе. Можно ли с этим что-то сделать?
IT>Как именно падает? С исключением? Можно примерчик?
Создали DbManager, обратились к базе. Dispose для DbManager не вызвали. Через нек. время все валится в финализаторе. т.е. проблема в том, что DbManager в финализаторе пытается освобождать managed объекты которые сами уже в непонятно каком состоянии.
Падает с таким StackTrace:
at System.Data.ProviderBase.DbConnectionInternal.PrePush(Object expectedOwner)
at System.Data.ProviderBase.DbConnectionPool.PutObject(DbConnectionInternal obj, Object owningObject)
at System.Data.ProviderBase.DbConnectionInternal.CloseConnection(DbConnection owningObject, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Close()
at System.Data.SqlClient.SqlConnection.Dispose(Boolean disposing)
at System.ComponentModel.Component.Dispose()
at BLToolkit.Data.DbManager.Close() in D:\Repository\dasBlog\trunk\BLToolkit\Source\Data\DbManager.cs:line 482
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Создали DbManager, обратились к базе. Dispose для DbManager не вызвали.
Почему?
TK>Через нек. время все валится в финализаторе. т.е. проблема в том, что DbManager в финализаторе пытается освобождать managed объекты которые сами уже в непонятно каком состоянии.
Странно, что соединение уже находится в непонятно каком состоянии. Его уже кто-то прибил до файналайзера?
Соединение можно передавать в DbManager как параметер, тогда DbManager не будет его диспозить.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
TK>>Создали DbManager, обратились к базе. Dispose для DbManager не вызвали. IT>Почему?
Юнит тест такой
IT>Странно, что соединение уже находится в непонятно каком состоянии. Его уже кто-то прибил до файналайзера?
SqlConnection тоже свой финалайзер имеет. Который может отработать раньше чем финалайзер DbManager...
IT>Соединение можно передавать в DbManager как параметер, тогда DbManager не будет его диспозить.
Это понятно.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
IT>>Странно, что соединение уже находится в непонятно каком состоянии. Его уже кто-то прибил до файналайзера?
TK>SqlConnection тоже свой финалайзер имеет. Который может отработать раньше чем финалайзер DbManager...
Судя по первоисточнику connection убирается из FQ ещё в конструкторе. Да и Dispose по идее должен быть написан так, чтобы он мог безопасно вызываться множество раз. Тут похоже успевает умереть не сам connection, а что-то внутри ADO.NET.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Вырезка из МСДН, помоему тут разночтений быть не может.
Dispose(bool disposing) executes in two distinct scenarios. If disposing equals true, the method has been called directly or indirectly by a user's code and managed and unmanaged resources can be disposed. If disposing equals false, the method has been called by the runtime from inside the finalizer and only unmanaged resources can be disposed. When an object is executing its finalization code, it should not reference other objects, because finalizers do not execute in any particular order. If an executing finalizer references another object that has already been finalized, the executing finalizer will fail.
Здравствуйте, FixBo, Вы писали:
IT>>И какой вывод?
FB>Такой что при disposing == false вообще ничего делать не надо. Сомневаюсь что в BLT найдется хоть один класс использующий unmanaged ресурсы...
DbConnection как раз один из таких.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>DbConnection как раз один из таких.
Как раз наоборот, в том то и дело что для внешнего пользователя это managed ресурс. Unmanaged можно считать например хендл файла если ты сам его открыл через экспорт CreateFile.
Даже если рассудить логически — откуда можно знать что скрывается в конкретной managed реализации и делать выводы — unmanaged он или managed?
Здравствуйте, FixBo, Вы писали:
FB>Как раз наоборот, в том то и дело что для внешнего пользователя это managed ресурс. Unmanaged можно считать например хендл файла если ты сам его открыл через экспорт CreateFile.
А FileStream тоже не надо считать unmanaged, если я его сам открыл?
FB>Даже если рассудить логически — откуда можно знать что скрывается в конкретной managed реализации и делать выводы — unmanaged он или managed?
В принципе, что-то в этом есть. Надо покумекать.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, FixBo, Вы писали:
FB>Unmanaged можно считать например хендл файла если ты сам его открыл через экспорт CreateFile.
Замечательно. Теперь представим себе, что у нас есть класс, одно из полей которого тот самый хендл файла, который нужно освобождать.
Этот класс в свою очередь является полем другого класса, к примеру, класса DbConnection. Если не dispose'ить DbConnection, то кто и когда освободит unmanaged ресурсы, используемые внутри класса, который внутри DbConnection?
Здравствуйте, Блудов Павел, Вы писали:
БП>Замечательно. Теперь представим себе, что у нас есть класс, одно из полей которого тот самый хендл файла, который нужно освобождать. БП>Этот класс в свою очередь является полем другого класса, к примеру, класса DbConnection. Если не dispose'ить DbConnection, то кто и когда освободит unmanaged ресурсы, используемые внутри класса, который внутри DbConnection?
При условии, что это хозяйство вызывается в файналайзере DbConnection, то файналазер нашего класса тоже будет вызван. Он и освободит. Логика в этом есть, но хорошо бы убедится на каком-нибудь примере, например, из ротора.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>А FileStream тоже не надо считать unmanaged, если я его сам открыл?
Конечно не надо, единственное что можно предпологать — он IDisposable и наверно (но не обязательно) имеет в себе unmanaged ресурс и из своего Dispose при disposing == true имеет смысл денуть и у него тоже чтоб пораньше освободить ресурсы. Но при GC сборке в этом нет необходимости — если ты держал последнюю ссылку то он сам собеется GC.
Если нам не помогут, то мы тоже никого не пощадим.
