|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
Добрый день, пытаюсь прикрутить SQLite к серверу, написанному на с#, все изменения таблиц провожу через транзакции в отдельном потоке: private static SQLiteTransaction transaction; private static Thread writeThread; private static List<string> writePull; private static long startTransactionTime; private static readonly long transactionDiration = 1000; ... static DataBaseController() { connection = new SQLiteConnection(connectionString); writePull = new List<string>(); } public static void ConnectionOpen() { connection.Open(); writeThread = new Thread(Writing); writeThread.Start(); Server.i.Log.Debug("data base connection OPENED, database name: " + dataBaseSource); } ... private static void Writing() { while (connection.State == System.Data.ConnectionState.Open) { if (transaction == null) { transaction = connection.BeginTransaction(); startTransactionTime = Environment.TickCount; } if (writePull.Count > 0) { Server.i.Log.Debug("writePull[0]: " + writePull[0]); SQLiteCommand cmd = new SQLiteCommand(writePull[0], connection, transaction); cmd.CommandText = writePull[0]; int queryResult = cmd.ExecuteNonQuery(); writePull.RemoveAt(0); Server.i.Log.Debug("end of writing"); } if (Environment.TickCount - startTransactionTime >= transactionDiration) { transaction.Commit(); transaction = null; } } } метод читает запросы для базы из списка запросов, которые добавляются туда другими методами: public static void SetCharacterLocation(string name, string city, string location) { string command = "UPDATE characterCommon SET city = '" + city + "', location = '" + location + "' WHERE name = '" + name + "'"; writePull.Add(command); } public static void SetCharacterHpEp(PlayerCharacter character) { string command1 = "UPDATE characterCommon SET currHp = " + character.data.currHp + ", WHERE name = '" + character.data.name + "'"; writePull.Add(command1); } выполнение первого запроса не вызывает проблем, но, когда метод пытается выполнить второй запрос, происходит сбой на строчке: int queryResult = cmd.ExecuteNonQuery(); на ней все приостанавливается, и сколько не жди, дальше ничего не выполняется, при этом сам SQLite ошибок не пишет в чем может быть проблема? настройки базы: http://my.jetscreenshot.com/demo/20130621-yb78-96kb ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2013, 11:15 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
с ошибкой разобрался, моя невнимательность меня подвела: character.data.currHp + ", WHERE name ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2013, 12:14 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
kernick, Склеивать запросы из строк не совсем эффективно. рекомендую сразу научиться и использовать биндинг - там просто ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2013, 12:41 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
я не знаю, что такое бандинг=), и чем не эффективно? - это та же строка, что прописывается в SQLiteСommand.CommandText ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2013, 14:24 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
с биндингом разобрался, но чем же он лучше? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.06.2013, 15:58 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
kernickс биндингом разобрался, но чем же он лучше?Любая СУБД, получив запрос выполняет его разбор, строит план исполнения и только потом начинает собственно исполнение запроса. Если запросы однотипные, но разные, то этапы разбора/построения плана могут (по времени) сравняться с этапом исполнения. Если разных однотипных запросов много и время от времени они повторяются, то возможна ситуация, когда ко времени повтора запрос уже вытеснен из кэша подготовленных и СУБД придётся опять тратить время на разбор и построение плана. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2013, 09:29 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
Basil A. Sidorov, Это объяснение верное, но не верное :) "этапы разбора/построения плана могут (по времени) сравняться с этапом исполнения." вот эта фраза не верна. Разбор запроса и построение плана это очень простая штука. Она всегда исчезающе мала по сравнению с этапом исполнения. В пользу биндинга есть два других аргумента: 1) Запрос это всегда текст. Не всегда значение которое надо послать в базу можно представить текстом. Например блобы или текст в utf16. Это самый главный аргумент за привязку параметров запроса, и иногда без нее просто не обойтись. 2) sql-injection. Если конструировать строку с запросом напрямую с данными переданными пользователем, то можно нарваться на хулигана. Привязка параметров эту возможность предотвращает на корню. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.06.2013, 19:08 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
White Owl"этапы разбора/построения плана могут (по времени) сравняться с этапом исполнения." вот эта фраза не верна. Разбор запроса и построение плана это очень простая штука. Она всегда исчезающе мала по сравнению с этапом исполнения. Это вы погорячились. Например, для запроса "SELECT 1 LIMIT 1 OFFSET 0;": Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Аналогично, многие "реальные" запросы содержат наборы различных условий, разбор которых занимает достаточно времени. Далее, построение плана запроса требует считывания гистограмм распределения данных, выбора путей объединения таблиц и нужных индексов и проч., и эта работа может быть весьма ресурсоемка относительно самого извлечения одной или нескольких строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2013, 00:57 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
MBGмногие "реальные" запросы содержат наборы различных условий, разбор которых занимает достаточно времени. Далее, построение плана запроса требует считывания гистограмм распределения данных, выбора путей объединения таблиц и нужных индексов и проч., и эта работа может быть весьма ресурсоемка относительно самого извлечения одной или нескольких строк.Да сколько бы они не содержали условий. Разбор запроса это всего-лишь прогон текста длиной ну максимум с сотню килобайт через лексер и парсер. Как они работают вам может рассказать любой человек кто делал свой компилятор, это не так уж сложно. Для определения плана запроса надо прочитать максимум десяток страниц со статистиками распределения. Но этот десяток набирается тогда, когда индекс разрастается соответствующе. В любом случае подготовка запроса никогда не превышает одного процента от времени выполнения этого запроса. А обычно это вообще доли процента. Экономить на спичках конечно можно, но смысл? Не лучше ли сам запрос оптимизировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2013, 06:19 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
White Owl"этапы разбора/построения плана могут (по времени) сравняться с этапом исполнения." вот эта фраза не верна. Разбор запроса и построение плана это очень простая штука. Она всегда исчезающе мала по сравнению с этапом исполнения.Кайт, специально для таких как вы, приводит разные примеры. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2013, 17:19 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
Basil A. SidorovWhite Owl"этапы разбора/построения плана могут (по времени) сравняться с этапом исполнения." вот эта фраза не верна. Разбор запроса и построение плана это очень простая штука. Она всегда исчезающе мала по сравнению с этапом исполнения.Кайт, специально для таких как вы, приводит разные примеры.Конкретнее пожалуйста. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.06.2013, 17:53 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
вот это холивары если вернуться к моей теме, то к базе имеет доступ только сервер через свою систему запросов, хулиганы ей не грозят. А что касается преимуществ биндинга, я все равно не до конца понимаю: все запросы, в моей ситуации, как бы они не строились сначала складируются строками в список, какая разница, как их туда писать с биндингом или напрямую? Если имелось ввиду, что биндинг позволяет строить однотипные запросы по одной схеме - я еще могу понять, что базе такие запросы парсить будет легче, но разве запрос можно написать как-то по другому?=) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2013, 10:18 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
"Проблема не в том, что человек смертен, а в том, что иногда он внезапно смертен". Сегодня вы наляпали запросов путём склейки строк, а завтра оказалось, что часть параметров придёт "откуда-то извне" и в один прекрасный день кто-нибудь отправит ту самую фигню, которая вам "не грозит". Сегодня вы наляпали запросов путём склейки строк, завтра наляпали ещё, а послезавтра взялись за разработку более-менее нагруженной системы и все мелочи, на которые вам было наплевать, стали проблемами. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2013, 17:01 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
White OwlКонкретнее пожалуйста."Oracle для профессионалов". В имеющемся у меня издании, глава 10, "Стратегии и средства настройки". В многопользовательской среде разборы начинают конкурировать за общий ресурс - каждый исполняется быстро, но этих каждых - (может быть) много. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2013, 19:47 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
Basil A. Sidorov"Проблема не в том, что человек смертен, а в том, что иногда он внезапно смертен". Сегодня вы наляпали запросов путём склейки строк, а завтра оказалось, что часть параметров придёт "откуда-то извне" и в один прекрасный день кто-нибудь отправит ту самую фигню, которая вам "не грозит". Сегодня вы наляпали запросов путём склейки строк, завтра наляпали ещё, а послезавтра взялись за разработку более-менее нагруженной системы и все мелочи, на которые вам было наплевать, стали проблемами.Соглашусь с первым, не соглашусь со вторым. Рефакторинг всегда найдет кучу проблем. И совершенно не важно было ли там формирование запроса путем склейки строк, путем чтения их из какой-то вспомогательной БД или запросы запрятаны внутрь хранимых процедур и представлений. Если ты взялся улучшать систему - проблемы найдутся всегда. Ни один рефакторинг не обходится без воплей: "Какой кретин это писал?! Ой, это же мой код." Не нужно представлять подход с привязкой параметров как панацею. У этого подхода тоже есть минусы: - Его сложнее поддерживать, больше кода на клиенте. Каждый параметр надо отдельно привязать, для каждого надо переменную завести... Как следствие и рефакторинг сложнее. - Клиент вынужден работать не с почти универсальным типом данных "строка" а со всей палитрой типов данных поддерживаемых базой. - Подготовленные запросы надо тщательно учитывать на клиенте - у большинства СУБД есть лимит сколько подготовленных запросов одновременно может быть внутри одного коннекта. У прямого запроса такого ограничения нет - он не хранится на сервере. - Ну и если уж вы любите экономить спички, то учитывайте что подготовленный запрос занимает некоторое количество памяти и на клиенте и на сервере. Оба подхода имеют право на жизнь. И константные запросы и параметризованные. У обоих есть свои плюсы и свои минусы. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2013, 19:58 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
Basil A. SidorovWhite OwlКонкретнее пожалуйста."Oracle для профессионалов". В имеющемся у меня издании, глава 10, "Стратегии и средства настройки". В многопользовательской среде разборы начинают конкурировать за общий ресурс - каждый исполняется быстро, но этих каждых - (может быть) много.А что-нибудь конкретное там приведено? Я не спорю с тем, что каждый раз парсить запрос перед выполнением будет занимать больше времени чем один раз подготовить и много раз выполнить. Я спорю с тем, что это самое "больше" будет очень велико. Я утверждаю, что в самом худшем случае, цикл с многократным разбором однотипных запросов будет медленнее чем выполнение подготовленного на доли процента . А в реальности потеря производительности будет совершенно не заметна. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.06.2013, 20:08 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
White OwlОба подхода имеют право на жизнь. И константные запросы и параметризованные. У обоих есть свои плюсы и свои минусы.... и они никак не соотносятся со сложностями разработки СУБД. P.S. Посчитал недавно количество классов эксплуатируемого нами приложения ... Более пяти тысяч. Собственных классов разработчиков. Без учёта внешних проектов. "Много думал", но так и не понял, почему написАть тысячи классов - нормально, а сотни запросов - нечто запредельное. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2013, 19:01 |
|
SQLite "виснет" на выполнении запроса без ошибки
|
|||
---|---|---|---|
#18+
White OwlА что-нибудь конкретное там приведено?Многопоточная вставка в трёх сценариях: 1. "Литерные" запросы; 2. Параметризованные запросы в режиме "подготовка, исполнении и так каждый раз"; 3. Более сложный и самый производительный вариант "один раз подготавливаем, а потом много раз выполняем". Первый случай - постоянные полные разборы (hard parse), второй - постоянные частичные разборы (soft parse), третий - разовый разбор и дальше - только исполнение. Второй вариант выигрывает у первого в разы, третий - полтора-два порядка у обоих. P.S. На реальной многопроцессорной системе ситуация, конечно, будет лучше, но тенденции - сохранятся. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.06.2013, 19:09 |
|
|
start [/forum/topic.php?fid=54&msg=38306479&tid=2008892]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
44ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
others: | 303ms |
total: | 451ms |
0 / 0 |