Спасибо за исследование! Это небольшое различие в значениях хеша лишило меня всякого сна и покоя, пришлось лезть разбираться, в чем же тут дело. И разобралось следующее.
Objects.hashCode опирается на алгоритм, приведенный в описании метода java.util.List.hashCode:
int hashCode = 1;
for (E e : list)
hashCode = 31*hashCode + (e==null ? 0 : e.hashCode())
private static int hashCombiner(int x, int y) {
return x*31 + y;
}
private static MethodHandle makeHashCode(Class<?> receiverClass,
List<MethodHandle> getters) {
//метод, всегда возвращающий 0
MethodHandle accumulator = MethodHandles.dropArguments(ZERO, 0, receiverClass);
for (MethodHandle getter : getters) {
//для примитивов hashCode их класса-обертки (Integer, Float и т.д.)
//а для объектов Objects.hashCode
MethodHandle hasher = hasher(getter.type().returnType());
MethodHandle hashThisField = MethodHandles.filterArguments(hasher, 0, getter);
//HASH_COMBINER это ссылка на метод hashCombiner выше
MethodHandle combineHashes = MethodHandles.filterArguments(
HASH_COMBINER, 0, accumulator, hashThisField);
accumulator = MethodHandles.permuteArguments(
combineHashes, accumulator.type(), 0, 0);
}
return accumulator;
}
Если не вдаваться к детали, то получается, что для записей алгоритм расчета хеша идентичен java.util.List.hashCode (тоже хеш элементов считает да на 31 умножает, ага) за исключением инициализации счетчика нулем, а не единицей. Могли бы ради единообразия подхода и тут с единицы считать начинать. Я бы тогда поспал :)
OJDBC Thin прекрасно умеет отменять запросы. Проблема тут скорее всего в другом.
Драйвер поддерживает несколько режимов отмены запроса. Самый продвинутый (out of band breaking) — через TCP-пакет с флагом urgent. Как только БД получает его, она прерывает запрос. Проблема в том, что некоторые активные участники сети любят сбрасывать этот флаг у пакета, в итоге отмена не срабатывает. В нашем компании именно так обстоит дело: что-то сбрасывает этот флаг. Проблема довольно популярная, по-моему в оракле версии 18 при установке соединения драйвер и база проверяют, нормально ли проходят urgent-пакеты. Если нет, то откатывается на старый режим работы, при котором запросы работают чуть медленнее, но при этом отмена работает стабильно. Запросы действительно работают медленее, мы гоняли тесты в разных комбинациях, и запрос из таблицы с сортировкой без индекса работал на 10% быстрее в случае thin. Где-то я читал, что это связано с необходимостью дополнительных опросов в БД, но подтверждений этому я не нашел, хотя на правду похоже.
Если драйвер начал использовать out of band breaking, а пакеты urgent режутся, то отмена произойдет в тот момент, когда БД отправит первый пакет клиенту, и у клиента появится возможность отправить серверу информацию о том, что уже хватит (как раз потому у вас происходила отмена после первой строки).
У thin можно принудительно включить такой же режим работы как и у thick, это делается через свойство oracle.net.disableOob. Выставьте его в true и проверьте, отмена может начать работать.
Сижу в офисе на cobra уже лет 5 или 6. Чтобы добавить перспективы — вешу килограмм 95 при росте 185. Отчасти согласен, что кресло хлипкое. Нет, оно не развалилось, но не очень охотно держит форму. Помогает посильнее затянуть крепления, тогда оно «уползает с настроек» довольно долго. «Лепестки» спинки немного проворачиваются — верх сходится, низ расходится, подголовник уползает вниз. Раз в пару месяцев спинку и подголовник надо повторно выставлять. Но за все время сидения то ли я принял форму кресла, то ли кресло как-то устаканилось, но последний год я ничего уже не подкручиваю, вроде и так удобно. Кстати, крепление подголовника действительно пугает своей хлипкость, но пока не сломалось (тфу-тфу-тфу), а ведь я любитель сидеть в кресле откинувшись.
К чему у меня серьезные претензии, так это к материалу подлокотников. Через пару лет элитный дерматин растянулся, пошел волнами, местами треснул. Функционально подлокотники не пострадали, но визуально стали выглядеть… страшно. Небольшая проблема с регулировкой глубины сидения (спинки). Со временем спинка уползает и ее надо возвращать назад. Не знаю, почему инженеры не сделали отверстия в пластине крепления, в которые можно вкрутить винт для жесткой фиксации. По их задумке, достаточно просто поджать эту пластину винтами, но в реальности мои 95кг успешно двигают спинку понемногу, оставляя на пластине хорошо заметные борозды от винтов.
Тем не менее, о покупке не жалею. От того, что нам закупает работодатель, у меня под вечер стабильно ныла поясница. На кобре о дискомфорте от длительного сидения я забыл.
Было бы отлично, если бы появилась возможность интегрировать gitlab и gerrit. У gerrit, к сожалению, управление репозитариями практически никакое, но вот code-review существенно превосходит модель pull/merge-request, на мой взгляд. Пользовался обеими, подход gerrit мне понравился гораздо больше. Я не думаю, что тут стоит проводить сравнение по пунктам, тем более есть множество дискуссий с детальным разбором плюсов и минусов обоих решений, их легко найти по фразе «github vs gerrit». Если бы была возможность взять управление репозитариями из gitlab, а code-review из gerrit, то связка бы получилась просто шикарная.
Спасибо за исследование! Это небольшое различие в значениях хеша лишило меня всякого сна и покоя, пришлось лезть разбираться, в чем же тут дело. И разобралось следующее.
Objects.hashCode опирается на алгоритм, приведенный в описании метода java.util.List.hashCode:
Для записей метод расчета хеша генерируется тут: java.lang.runtime.ObjectMethods.makeHashCode(Class<?>, List).
Я выделил самые, на мой взгляд, важные части:
Если не вдаваться к детали, то получается, что для записей алгоритм расчета хеша идентичен java.util.List.hashCode (тоже хеш элементов считает да на 31 умножает, ага) за исключением инициализации счетчика нулем, а не единицей. Могли бы ради единообразия подхода и тут с единицы считать начинать. Я бы тогда поспал :)
Драйвер поддерживает несколько режимов отмены запроса. Самый продвинутый (out of band breaking) — через TCP-пакет с флагом urgent. Как только БД получает его, она прерывает запрос. Проблема в том, что некоторые активные участники сети любят сбрасывать этот флаг у пакета, в итоге отмена не срабатывает. В нашем компании именно так обстоит дело: что-то сбрасывает этот флаг. Проблема довольно популярная, по-моему в оракле версии 18 при установке соединения драйвер и база проверяют, нормально ли проходят urgent-пакеты. Если нет, то откатывается на старый режим работы, при котором запросы работают чуть медленнее, но при этом отмена работает стабильно. Запросы действительно работают медленее, мы гоняли тесты в разных комбинациях, и запрос из таблицы с сортировкой без индекса работал на 10% быстрее в случае thin. Где-то я читал, что это связано с необходимостью дополнительных опросов в БД, но подтверждений этому я не нашел, хотя на правду похоже.
Если драйвер начал использовать out of band breaking, а пакеты urgent режутся, то отмена произойдет в тот момент, когда БД отправит первый пакет клиенту, и у клиента появится возможность отправить серверу информацию о том, что уже хватит (как раз потому у вас происходила отмена после первой строки).
У thin можно принудительно включить такой же режим работы как и у thick, это делается через свойство oracle.net.disableOob. Выставьте его в true и проверьте, отмена может начать работать.
К чему у меня серьезные претензии, так это к материалу подлокотников. Через пару лет элитный дерматин растянулся, пошел волнами, местами треснул. Функционально подлокотники не пострадали, но визуально стали выглядеть… страшно. Небольшая проблема с регулировкой глубины сидения (спинки). Со временем спинка уползает и ее надо возвращать назад. Не знаю, почему инженеры не сделали отверстия в пластине крепления, в которые можно вкрутить винт для жесткой фиксации. По их задумке, достаточно просто поджать эту пластину винтами, но в реальности мои 95кг успешно двигают спинку понемногу, оставляя на пластине хорошо заметные борозды от винтов.
Тем не менее, о покупке не жалею. От того, что нам закупает работодатель, у меня под вечер стабильно ныла поясница. На кобре о дискомфорте от длительного сидения я забыл.