Колупаю Go-шный драйвер для FB
Есть проблема с некорректным разбором ответа сервера, если был exception в селективной процедуре.

Логика разбора ответа op_fetch следующая:
- пропускаются все op_dummy
- парсится op_response если счетчик lazyResponseCount > 0
- далее ожидается op_fetch_response
тут и проблема, т.к. прилетает op_response с ошибкой

Понятно, что этот op_response надо обработать, в связи с этим несколько вопросов:
1. op_response всегда будет содержать ошибку?
2. может ли быть еще что-то кроме op_fetch_response и op_response?
3. нужно ли после op_response отправлять op_free_statement с DSQL_close?

Коваленко Дмитрий,

с с++ я чуть меньше чем никак ((

по первому пункту понял что всегда exception
по второму если не op_fetch_response и не op_response - exception
по третьему чет не узрел

Коваленко Дмитрий,
> op_free_statement с DSQL_close - это другая операция. К "выборке данных из курсора" отношения не имеет.
понятно, меня интересует, если я в ответ на op_fetch получил op_response курсор на стороне сервера еще жив или нет?

hvlad, Коваленко Дмитрий
спасибо

авторКолупаю Go-шный драйвер для FB

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

Правильно ли будет игнорировать такие ошибки?

В текущей реализации отложенные op_response ожидаются для op_allocate_statement=62, op_free_statement=67 и op_close_blob=39. Для op_allocate_statement даже отложенный op_response будет обработан в том же методе (т.к. нужно вытащить statement handle). В пропуске ошибок для op_free_statement и op_close_blob криминала вроде нет. Или есть?

Есть ли еще запросы кроме этих, после которых может прилететь отложенный op_response?

Хочу так же прояснить вопрос с op_dummy.
Как часто сервер присылает op_dummy и в каких местах его можно ожидать?
По текущей реализации логика мне не ясна, где-то есть проверки, где-то нет. Может надо проверять при чтении любого опкода от сервера?

Мимопроходящий,

а что делать...
вдруг кто мимо проходить будет да подскажет

подглядел реализацию в jaybird
вопрос про игнор ошибок в отложенных op_response отпал - игнор
https://github.com/FirebirdSQL/jaybird/blob/master/src/main/org/firebirdsql/gds/ng/wire/version11/V11WireOperations.java#L57

вопросы про op_dummy отпали - проверяем при чтении каждого опкода
https://github.com/FirebirdSQL/jaybird/blob/master/src/main/org/firebirdsql/gds/ng/wire/WireConnection.java#L463

остался один вопрос
Есть ли еще запросы, кроме op_allocate_statement=62, op_free_statement=67 и op_close_blob=39, после которых может прилететь отложенный op_response?

т.е. сервер в любом случае отправит ответ?

я думал что сервер тоже может придержаь ответ. Меня смутило различие в реализациях протокола в jaybbird. Если это чисто клиентская фишка то почему в реализации протокола в v10 этого нет, а в v11 есть. Плюс реализация с которой я работаю, флаг, который управляет откладывать разбор ответа на потом или нет, читает из ответа сервера на op_attach?

ну это же то что надо, огромное спасибо за ответ

авторМогут задержаться ответы на op_allocate_statement, op_execute, op_release, op_free_statement.

Ответы на op_execute задерживаются только если ожидается op_fetch, т.е. речь о курсоре.
Вот тут решает сервер: если он во время op_prepare вернул в поле p_resp_object ответа флаг STMT_DEFER_EXECUTE (4), то ответ на op_execute будет задержан.

op_allocate_statement: в случае отложенного ответа что отправлять в качестве statement handle?
эта реализация использует -1 (0xFFFFFFFF), jaybird 0xFFFF, если не ошибаюсь.

За подробности про op_execute спасибо, надо только разобраться где искать p_resp_object в op_prepare.
- 4 байта Object handle
- 8 байт Object ID
- 4 байта длина + буфер с длиной выровненой до 4 (его назначение мне пока не ясно)
- дальше разбор статус вектора
Object ID это оно?

с op_release не сталкивался, с op_free_statement вроде все ок.

авторОтветы на op_close_blob не задерживается, не знаю, откуда ты это взял.
видел отложенную обработку ответов op_close_blob и op_cancel_blob в jaybird

спасибо
и еще одино момент - при каких условиях сервер возвращает STMT_DEFER_EXECUTE? как это воспроизвести чтобы протестировать

hvlad,

Вопрос именно в том как заставить сервер вернуть флаг STMT_DEFER_EXECUTE и отложить ответ на op_execute?
Судя по тому что сейчас нет обработки такого случая и это работает без зависаний, на такое пока не нарывались. Сервисы с этим драйвером работают на бою и давно.

очередное спасибо за разъяснение нюансов


теперь понятно, драйвер всегда читает ответ после выполнения, потому и не столкнулись с этим кейсом