iBase.ru Forum

Привет всем.
Я использую freeradius 1.0.5 как аккаунтинговый сервер. Аккаунтинговая информация хранится в фаябирдовской базе данных (FB 1.5.2, Linux). Доступ к базе осуществляется или через odbc (sql-драйвер rlm_sql_unixodbc, odbc драйвер взят здесь:
http://prdownloads.sourceforge.net/fire ... .69.tar.gz),
или напрямую через API (sql-драйвер rlm_sql_firebird, самописный).

Не могу понять следующую ситуацию:

После заливки нового IOS-а cisco стала слать одновременно два ALIVE пакета. В первом пакете аттрибут Framed-IP-Address равен пустой строке, во втором IP адресу полученному от радиуса. Соответственно имеем одновременный апдейтит одной и той же записи в разных транзакциях. При доступе к БД через odbc эта ситуация почти всегда успешно разрешается, а в случае прямого доступа (через API) где-то в 90% случаев получаю deadlock. При этом, судя по всему(беглый просмотр сырцов odbc-драйвера), уровень изоляции транзакций в обоих случаях (и при использование API, и при использовании odbc) одинаков:

isc_tpb_version3
isc_tpb_wait
isc_tpb_write
isc_tpb_read_committed
isc_tpb_no_rec_version

Проблема не критична(так как в случае ошибки пакет через несколько секунд пересылается вновь), но слегка действует на нервы. Кто-нибудь может дать объяснение или высказать предположение почему odbc почти всегда разруливает это дело, а прямой доступ к БД - нет (уж очень не хочется ковырять сырцы odbc-драйвера и freeradius-а)?

P.S. Гипотеза о "кривых руках" выдвинута в первую очередь и проверяется до сих пор, но пока не находит подтверждения, хотя и помогла выявить некоторые глюки

Использовать no_rec_version - верный способ получить деадлок.

Dimitry Sibiryakov писал(а):Использовать no_rec_version - верный способ получить деадлок.

Я проверял раньше, сейчас проверил еще раз и согласно моим опытам, верный способ получить deadlock это использование rec_version. Проверь тоже, если не трудно плиз.

А мне не на чем проверять - нет задач которые бы апдейтили одну запись одновременно.

Dimitry Sibiryakov писал(а):А мне не на чем проверять - нет задач которые бы апдейтили одну запись одновременно.

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

Есть тут один источник... По имени Энн. И фамилии Гаррисон. Обычно надежный.

А вот ещё один источник

а почему isc_tpb_version3 ? зачем ты ее вообще в tpb указываешь в IBX?

Andrew Sagulin писал(а):А вот ещё один источник

Лажа, иззиняюсь. Для двух транзакций - да, больше - стохастически.

kdv писал(а):а почему isc_tpb_version3 ? зачем ты ее вообще в tpb указываешь в IBX?

Дмитрий, какой IBX, прости господи??????

2Merlin
Ну ты ж чуть ли не самый умный, может у тебя какие идеи есть? Почему odbc не дедлочит?

v6y писал(а):Почему odbc не дедлочит?

Потому что не делает это одновременно ?

hvlad писал(а):

v6y писал(а):Почему odbc не дедлочит?

Потому что не делает это одновременно ?

Думал я об этом... Система у freeradius-а такая, что каждый accounting-request (в зависимости от используемого sql-драйвера) обрабатывается отдельным подключеним либо к базе, либо к odbc-источнику. Но тогда, как мне кажетя, odbc должен либо быть слишком тормозным (или слишком быстрым ), либо у него должно быть что то наподобие очереди запросов - типа выполнил, закомиттил. В любом случае что бы выяснить нужно odbc-шные сырцы копать, а мне этого делать ну очень не хочется.