setConnection для прямых запросов на SQL

[Corel]

Есть такая вещь, как setConnection() - устанавливает отдельное соединение для запроса к таблице, которое существует изолированно от основной транзакции. Например, так работает выделение номеров в NumberSquenceTable.

Вопрос: а можно как-то в отдельном соединении запустить executeQuery()? Возможно, надо просто как-то по-другому инициализировать Connection?

ResultSet get(str _sql)
{
    ResultSet rs;
    Connection con = new Connection();
    ;

    new SqlStatementExecutePermission(_sql).assert();
    rs = con.createStatement().executeQuery(_sql);
    CodeAccessPermission::revertAssert();
    return rs;
}

P.S. речь про 2009

[Alex_KD]

SysOperation запустить ассинхронно?

Какую проблему решить пытаетесь?

[Corel]

SysOperation - оно для 2012 же только? Тогда не годится.
Задача - вставить значение, полученное во время работы кода, в отдельную таблицу на SQL. Значение обычно получается в глубинах транзакций, а вставить в эту отдельную таблицу пытаются часто и разные АОСы. Поэтому нередки ситуации, когда во время работы долгой обработки, которая дошла до этой вставки, сделала её и пошла дальше, все остальные процессы, которые хотят сделать такую же вставку, вынуждены ждать завершения этой обработки.

[Alexius]

Скорее всего на таблице отсутствует уникальный индекс и при вставке записи в нее она блокируется целиком.

PS. Желателен даже Primary Index.

[Corel]

Хм, разве это так работает? На таблице индекса вообще нет, да и нужен ли, если идёт только вставка?
И всё же, если вернуться к изначальному вопросу: возможно ли эту операцию (вызов SQL-запроса) оформить изолированной транзакцией?
Или вызов SQL-запроса через Statement.executeQuery() и так изолирован и действительно дело в блокировке все таблицы при любой вставке?

[Alexius]

Что бы победить врага, его нужно сначала найти.
Проблемы блокировок разбирались на этом форуме кучу раз.
Когда вы найдете таблицу, на которой все стопорится, то это уже будет уже пол дела.

Если у вас есть серьезные основания подозревать, что блокировка происходит именно на скулевой-неАХ табличке, то сделайте джоб со вставкой в нее и с помощью двух клиентских сессий проверьте это. Для этого в одной сессии прямо на ttscommit ставите брэк-поинт в джобе, запускаете его и он останавливается, а в другой пытаетесь выполнить джоб целиком. Результат ?

[Владимир Максимов]

Цитата:

Сообщение от Corel

И всё же, если вернуться к изначальному вопросу: возможно ли эту операцию (вызов SQL-запроса) оформить изолированной транзакцией?

Возможно, конечно. Вы код в номерной серии внимательно посмотрели? xRecord.setConnection() указывает, что с этой табличной переменной надо работать через ранее созданное другое соединение. Т.е. соединение сначала надо все-таки создать. Внимательно посмотрите как создается это новое соединение. Через какой класс.

Есть 3 типа создаваемых соединений. 3 класса

Connection - "поднимает" текущее, уже существующее соединение
UserConnection - создает новое соединение, но с реквизитами существующего
ODBCConnection - создает новое соединение по указанным реквизитам

Цитата:

Сообщение от Corel

Или вызов SQL-запроса через Statement.executeQuery() и так изолирован и действительно дело в блокировке все таблицы при любой вставке?

Зависти от используемого типа соединения. Собственно, давно бы уже проверили Сценарий теста Вам уже подсказали.