Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Начинающим";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Вниз

Достаточно ли одного ADOConnection?   Найти похожие ветки 

 
leklerk ©   (2012-03-06 13:08) [0]

У меня в программе для двух ADODataSet и двух ADOCommand используется один ADOConnection. Можно так делать или нужно для каждого ADODataSet и ADOCommand создавать свой ADOConnection?


 
stas ©   (2012-03-06 13:27) [1]

Достаточно одного.


 
Ega23 ©   (2012-03-06 13:54) [2]

"Свой" ADOConnection имеет смысл создавать:
а) При обращении к "другой" БД
б) При работе с БД из нескольких тредов (либо по своему коннекту на тред, либо общий пул коннектов).
В 95% случаев достаточно одного единственного соединения.
Даже в 99%. :)


 
Alex_C   (2012-03-06 18:07) [3]


> При работе с БД из нескольких тредов


Вот этот бы момент еще до конца просвятить. :)
Сколько не пытался получить проблему при использовании одного ADOConnect"а из нескольких тредов - не получалось.
Так надо все же или это рекомендательный характер носит совет?


 
stas ©   (2012-03-06 19:14) [4]

Alex_C   (06.03.12 18:07) [3]
Смотря какая СУБД. я как-то приводил примеры.

Например явная ошибка в  MS Aсcess (ядро JET): чтобы получить последний ID нужно выполнить запрос Select @@IDENTITY  при этом ты получаешь последний ID в пределах подключения. Естественно если у тебя 10 потоков, то ты не сможешь узнать в каждом потоке ID последней вставленной записи.


 
sniknik ©   (2012-03-06 19:50) [5]

> Например явная ошибка в  MS Aсcess (ядро JET):
нет там ошибки, просто нужно помнить что каждое соединение это COM объект, ну и то что чудес не бывает.


 
Ega23 ©   (2012-03-06 21:26) [6]


> Сколько не пытался получить проблему при использовании одного
> ADOConnect"а из нескольких тредов - не получалось.


Просто повезло.
Это как с
try
 obj := TSomeObject.Create;
 ...
finally
 obj.free;
end;
 

В некоторых случаях - нарвёшься. В некоторых - нет. Рисковать - выбор за тобой.
Ну и таки да, ADOConnection - COM-объект.


 
DVM ©   (2012-03-06 23:05) [7]


> Alex_C   (06.03.12 18:07) [3]


> Сколько не пытался получить проблему при использовании одного
> ADOConnect"а из нескольких тредов - не получалось.

Это проще простого организовать, даже я бы сказал элементарно. Много раз наблюдал. Ничего страшного причем не случается (по крайней мере на SQL сервере), ADO сыпет ошибками в которых говорится что-то про подключения из разных потоков и утечки памяти иногда возникают. Чтобы сие получить надо множество потоков (штук 10 например) и более одного ядра на процессоре.


 
Loginov Dmitry ©   (2012-03-06 23:24) [8]


> Сколько не пытался получить проблему при использовании одного
> ADOConnect"а из нескольких тредов - не получалось.


Нельзя одновременно из нескольких потоков работать с одним компонентом-подключением!
см. обоснование:
http://www.loginovprojects.ru/index.php?page=threadsafedb


 
Alex_C   (2012-03-07 10:05) [9]


> см. обоснование:


Прочитал. Спасибо! Но тут , по моему вступает в действие


> Смотря какая СУБД.


Сейчас на вскидку статью не найду, но вроде как MS писала, что связка ADO+Access является потокозащищенной.

Вообще на самом деле почему такой вопрос возникает: одно ADOConnection использовать, или несколько: опять же применительно к связке ADO+Access при использовании нескольких ADOConnection  возникают проблемы видимости добавленных/измененных записей через разные ADOConnection.
Я тут некоторое время назад спрашивал, как такие проблемы решить, но так ответа и не получил.


 
Ega23 ©   (2012-03-07 10:38) [10]


> при использовании нескольких ADOConnection  возникают проблемы
> видимости добавленных/измененных записей через разные ADOConnection.


Не возникает никаких проблем. Кури про транзакции и уровни их изоляции.


 
sniknik ©   (2012-03-07 12:05) [11]

>> при использовании нескольких ADOConnection  возникают проблемы
>> видимости добавленных/измененных записей через разные ADOConnection.
> Не возникает никаких проблем.
+1

> Сейчас на вскидку статью не найду, но вроде как MS писала, что связка ADO+Access является потокозащищенной.
а постарайся, может ты что не так так понял. (там есть свои потоки, асинхронность, это да. а вот как может быть защищенной связка из разных внешних потоков, при том что для модели COM нужна инициализация каждого отдельно. объекты полностью изолированны со своими переменными, и вообще возможно отдельными базами...  ну в общем хотелось бы посмотреть первоисточник.)

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


 
DVM ©   (2012-03-07 12:38) [12]


> Alex_C   (07.03.12 10:05) [9]


> но вроде как MS писала, что связка ADO+Access является потокозащищенной.
>  

Если даже так, то все равно TAdoConnection не потокобезопасен.


 
Anatoly Podgoretsky ©   (2012-03-07 13:17) [13]

> DVM  (07.03.2012 12:38:12)  [12]

Потоко безопасность обеспечивается правильным использованием.


 
Ega23 ©   (2012-03-07 13:57) [14]


> как лечить оранжевую чупакабру


Чупакабра не бывает оранжевой. На самом деле это супермутант со вколотым селсом, который обитает за камушком на юго-востоке от Новака.


 
Alex_C   (2012-03-07 14:48) [15]


> Кури про транзакции и уровни их изоляции.


Сейчас посмотрел в чем был вопрос:
если из одного LogConnection удалить запись, то в другом она все равно остается видимой. При вставке записи - все ок!


 
Alex_C   (2012-03-07 15:04) [16]


> одного LogConnection удалить запись


Вру! :) Все работает! Вопрос снимается... До следующих Вопросов! :)



Страницы: 1 вся ветка

Форум: "Начинающим";
Текущий архив: 2013.03.22;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.058 c
15-1330181581
Pcrepair
2012-02-25 18:53
2013.03.22
TWebBrowser портит ссылки в коде страницы


15-1337373003
Юрий
2012-05-19 00:30
2013.03.22
С днем рождения ! 19 мая 2012 суббота


15-1338220756
brother
2012-05-28 19:59
2013.03.22
Как Вы прочитали это: CoCu ?


15-1332164769
Empleado
2012-03-19 17:46
2013.03.22
Работа с формулами


8-1229748560
Лена111
2008-12-20 07:49
2013.03.22
Перерисовывать ЛистБокс до не узнаваимости





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский