Возьмём xterm и сконфигурим его по старинке (через core X fonts):

*.vt100.renderFont:             False
*.vt100.locale:                 False
*.vt100.font:                   -monotype-courier new-medium-r-normal--*-120-*-*-m-*-koi8-r

При этом в тесте vttest символы удвоенного размера будут отображаться корректно:

картинка

Теперь сконфигурим его, чтобы использовал клиентские шрифты через библиотеку Xft:

*.vt100.renderFont:             True
*.vt100.faceName:               Courier New:antialias=false
*.vt100.faceSize:               12
*.vt100.utf8:                   1
*.vt100.utf8Fonts:              True
*.vt100.utf8Title:              True

После этого исмволы удвоенного размера отображаться перестанут:

картинка

ИЧСХ, в PuTTY и konsole тот же тест проходится на «ура», хотя обе программы тоже используют клиентские шрифты. Чёрт побери, даже на «маке» в стандартном Terminal.app всё корректно. Ну, в rxvt всё, ясное дело, отродясь не работало.

Что это? Я хреново нестроил xterm? Или это известный баг?

Я по-прежнему использую core X11 fonts.

В свете того, что из Debian выпилили xfs, а пересобрать libxft2 с нужными ключами и опакетить оба компонента под Debian 9 я так и не собрался (готов дать денег тому, кто сделает это за меня либо сэкономит моё время, проведя через адъ утилит dh_* и бюрократию WNPP), фрагмент моего xorg.conf сейчас выглядит так:

Section "Files"
	ModulePath   "/usr/lib/xorg/modules"
	FontPath     "unix/:7100"
	FontPath     "/usr/share/fonts/X11/misc"
	FontPath     "/usr/share/fonts/X11/cyrillic"
	FontPath     "/usr/share/fonts/X11/100dpi/:unscaled"
	FontPath     "/usr/share/fonts/X11/75dpi/:unscaled"
	FontPath     "/usr/share/fonts/X11/Type1"
	FontPath     "/usr/share/fonts/X11/100dpi"
	FontPath     "/usr/share/fonts/X11/75dpi"
	FontPath     "built-ins"
	FontPath	"/usr/share/fonts/opentype/cantarell"
	FontPath	"/usr/share/fonts/opentype/fonts-prociono"
	FontPath	"/usr/share/fonts/opentype/freefont"
	FontPath	"/usr/share/fonts/opentype/linux-libertine"
	FontPath	"/usr/share/fonts/opentype/radisnoir"
	FontPath	"/usr/share/fonts/opentype/scheherazade"
	FontPath	"/usr/share/fonts/opentype/stix"
	FontPath	"/usr/share/fonts/opentype/stix-word"
	FontPath	"/usr/share/fonts/opentype/yozvox-yozfont"
	FontPath	"/usr/share/fonts/sortsmill"
	FontPath	"/usr/share/fonts/truetype"
	FontPath	"/usr/share/fonts/truetype/adf"
	FontPath	"/usr/share/fonts/truetype/aenigma"
	FontPath	"/usr/share/fonts/truetype/alee"
	FontPath	"/usr/share/fonts/truetype/ancient-scripts"
	FontPath	"/usr/share/fonts/truetype/anonymous-pro"
	FontPath	"/usr/share/fonts/truetype/arundina"
	FontPath	"/usr/share/fonts/truetype/baekmuk"
	FontPath	"/usr/share/fonts/truetype/dejavu"
	FontPath	"/usr/share/fonts/truetype/denemo"
	FontPath	"/usr/share/fonts/truetype/droid"
	FontPath	"/usr/share/fonts/truetype/engadget"
	FontPath	"/usr/share/fonts/truetype/femkeklaver"
	FontPath	"/usr/share/fonts/truetype/fifthhorseman"
	FontPath	"/usr/share/fonts/truetype/fonts-arabeyes"
	FontPath	"/usr/share/fonts/truetype/fonts-atarismall"
	FontPath	"/usr/share/fonts/truetype/fonts-georgewilliams"
	FontPath	"/usr/share/fonts/truetype/fonts-prociono"
	FontPath	"/usr/share/fonts/truetype/fonts-tiresias"
	FontPath	"/usr/share/fonts/truetype/freefarsi"
	FontPath	"/usr/share/fonts/truetype/freefont"
	FontPath	"/usr/share/fonts/truetype/gentium"
	FontPath	"/usr/share/fonts/truetype/gentium-basic"
	FontPath	"/usr/share/fonts/truetype/hanazono"
	FontPath	"/usr/share/fonts/truetype/isabella"
	FontPath	"/usr/share/fonts/truetype/jsmath"
	FontPath	"/usr/share/fonts/truetype/junicode"
	FontPath	"/usr/share/fonts/truetype/kacst"
	FontPath	"/usr/share/fonts/truetype/kacst-one"
	FontPath	"/usr/share/fonts/truetype/lato"
	FontPath	"/usr/share/fonts/truetype/liberation"
	FontPath	"/usr/share/fonts/truetype/lyx"
	FontPath	"/usr/share/fonts/truetype/mikachan"
	FontPath	"/usr/share/fonts/truetype/mph-2b-damase"
	FontPath	"/usr/share/fonts/truetype/mplus"
	FontPath	"/usr/share/fonts/truetype/msttcorefonts"
	FontPath	"/usr/share/fonts/truetype/noto"
	FontPath	"/usr/share/fonts/truetype/openoffice"
	FontPath	"/usr/share/fonts/truetype/sjfonts"
	FontPath	"/usr/share/fonts/truetype/tlwg"
	FontPath	"/usr/share/fonts/truetype/tomsontalks"
	FontPath	"/usr/share/fonts/truetype/ttf-bitstream-vera"
	FontPath	"/usr/share/fonts/truetype/ttf-dejavu"
	FontPath	"/usr/share/fonts/truetype/ttf-essays"
	FontPath	"/usr/share/fonts/truetype/ttf-liberation"
	FontPath	"/usr/share/fonts/truetype/ttf-marvosym"
	FontPath	"/usr/share/fonts/truetype/ttf-staypuft"
	FontPath	"/usr/share/fonts/truetype/ttf-summersby"
	FontPath	"/usr/share/fonts/truetype/ttf-tagbanwa"
	FontPath	"/usr/share/fonts/truetype/ttf-xfree86-nonfree"
	FontPath	"/usr/share/fonts/truetype/ttf-xfree86-nonfree-syriac"
	FontPath	"/usr/share/fonts/truetype/unifont"
	FontPath	"/usr/share/fonts/truetype/wqy"
	FontPath	"/usr/share/fonts/truetype/yanone-kaffeesatz"
EndSection

В каждом из каталогов из списка – сгенерённые fonts.dir и fonts.scale.

Хотя, если бы в системе был xfs, то весь этот зоопарк попал бы в /etc/X11/fs/config, но от этого не перестал бы быть зоопарком.

И вот хочется этот процесс автоматизировать:

• автоматически регистрировать/дерегистрировать в xorg.conf и/или /etc/X11/fs/config каталоги при установке и удалении шрифтов;
• автоматически создавать fonts.dir и fonts.scale при установке/обновлении пакетов и удалять при удалении.

Раньше (Debian 6 и ранее) всем этим занимался _Defom_a (1, 2), но метаинформацию ему предоставляли сопровождающие пакетов со шрифтами (чего сейчас они делать, вестимо, не будут).

Сейчас я посмотрел на соотв. триггеры в Debian 9, но состояние там малоутешительное: в /etc/X11/fonts/* можно создать свои *.dir/*.scale/*.alias (через dh_installxfonts), но, во-первых, это должен сделать сам сопровождающий пакета, и, во-вторых, это работает только для шрифтов, устанавливаемых в /usr/share/fonts/X11/:

# PROMISE: DH NOOP WITHOUT tmp(usr/share/fonts/X11)

foreach my $package (@{$dh{DOPACKAGES}}) {
        my $tmp=tmpdir($package);

        # Find all font directories in the package build directory.
        my @fontdirs;
        foreach my $parentdir ("$tmp/usr/share/fonts/X11/") {
                opendir(DIR, $parentdir) || next;
                @fontdirs = grep { -d "$parentdir/$_" && !/^\./ } (readdir DIR);
                closedir DIR;
        }

        # ...
}

Можно ли решить проблему через дебиановские триггеры? Может, я таки до конца не разобрался?

Или какие альтернативы посоветуете?

Дебановских машин несколько (рабочая, домашняя, несколько мобильных), поэтому подход «напиши на bash цикл и запускай его каждый раз после обновления пакетов» не нравится.

Запускать виртуальную машину со старым Debian Squeeze и xfs и забирать шрифты с tcp://squeeze-vm:7100 тоже не хочется.

Собственно, тестирую запись видео с основного монитора на Mac OS X. Видео записываю с помощью ffmpeg, на Mac OS X использую входное устройство avfoundation:

ffmpeg -y -v error -hide_banner -f avfoundation -i 1:none -threads 0 -f mp4 -vcodec mpeg4 -r 25/1 -qscale:v 1 output.mp4

Проблема в том, что в результирующем видеофайле размер растра всегда вчетверо больше, чем разрешение экрана (т. е. при разрешении в 1920x1200 я получаю видео в разрешении 3840x2400, и так для каждого из разрешений, доступных через стандартные настройки системы (ну т. е. если не использовать утилиту screenresolution и прочие извращения)).

Скриншоты творящегося безобразия здесь.

Вопросов, как водится на Руси, два:

• Какого хрена?
• Что делать, чтобы размер растра видео всегда точно совпадал с разрешением экрана? Суб-самплинг (-vf scale=...) включать не хочу.

Заранее спасибо.

https://admin.hostpoint.ch/pipermail/enigmail-users_enigmail.net/2019-January/005280.html

Печально, но это было неизбежно.

Неизбежно и то, что, если сам проект Enigmail не перейдёт на WebExtensions, то и он будет мёртв в течение года-двух…

Собственно, ${subj}.

Купил новый монитор (DP/HDMI/DVI-D). VGA нет.

При этом есть куча старого железа, у которого выход только VGA. Соответственно, нужен активный адаптер, преобразующий аналоговый сигнал (VGA) в цифровой. Проблема, я так понял, обостряется ещё и тем, что существующие на рынке решения обычно умеют в 1080p, максимум — в 1200p (по вертикали). Теоретически какой-нибудь древний Matrox G500 с его традиционно охренительным 2d (а одна из железок у меня именно такая) способен на гораздо более высокое разрешение.

Что посоветуете?

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

Заранее спасибо.

Собственно, правда — как?

• На маке (MacVim), делается легко и непринуждённо через noantialias.
• Для GTK2 решается добавлением antialias=false к запросу к fontconfig: Courier New:size=12:antialias=false:rgba=rgb.
• Для Motif, Athena и GTK1... ну, в общем, и так всё понятно.

А как сделать то же самое для gui_win32?

Собственно, сабж.

В Eclipse 4.8 (вернее в SWT) индусы сломали поддержку GTK2, не смогли её починить, и потому в 4.10 выпилили её нахрен вообще.

Соответственно, возникает вопрос выбора пристойной GTK3-темы.

Проблема в том, что

а) хочется светлой темы (т. е., скажем, Blackbird не подходит);

б) «олдскульные» темы, которые имитируют всякие Raleigh, Motif'ы и NextStep'ы, работают прекрасно на примитивных приложениях типа GEdit, но в случае с Eclipse вылезает множество рамок (borders) невидимых элементов (пример);

в) в мейнстримовых темах оформления (Adwaita, Breeze, Greybird, Numix) экранное пространство жрётся как не в себя, в результате чего на тулбаре помещается на 10% меньше кнопок, ну и все UI-элементы тоже на 10% больше, как будто я совсем уже крот. Похоже, авторы тем ориентировались на владельцев 4k-мониторов, а на нищебродов типа меня, у кого 1920x1200, тупо забили.

Я на эту тему запилил багрепорт, но маловероятно, что воспоследует какая-л. реакция.

Короче, посоветуйте тему, пожалуйста.

Типа, чуваки готовятся к рождеству =)

https://www.qemu-advent-calendar.org/2018/

Товарищи, приветствую.

У кого стоит Thunderbird в связке с (последним) Enigmail 2.0.8 — вы можете протестировать поведение, описанное вот в этой заявке, и сообщить о результатах?

Хочу понять, специфична ли проблема для SeaMonkey, или это такая общая регрессия.

Проявляется только на 2.0.8 — в 2.0.7 и ранее всё норм.

Всем заранее спасибо.

Всем здравствуйте.

У кого есть Мак (или Хакинтош — неважно) и есть установленный из HomeBrew, Fink или MacPorts ffmpeg — пришлите, пожалуйста, вывод следующих трёх команд:

ffmpeg -hide_banner -f avfoundation -list_devices true -i ""; echo $?
ffmpeg -hide_banner -f avfoundation -list_devices true -i "" 2>/dev/null; echo $?
ffmpeg -hide_banner -f avfoundation -list_devices true -i "" -v error; echo $?

Нужно для статистики, ибо сам ни разу не маковод.

Заранее спасибо.

Здравствуйте.

Вот есть вот такой фрагмент xorg.conf:

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen          0 "Screen0" Absolute    1920 0
        Screen          1 "Screen1" LeftOf      "Screen0"
EndSection

Section "Monitor"
        Identifier      "HDMI1"
        Option          "PreferredMode" "1920x1080"
        Option          "Primary"       "True"
EndSection

Section "Monitor"
        Identifier      "DP1"
        Option          "PreferredMode" "1920x1200"
        Option          "LeftOf"        "HDMI1"
EndSection


Section "Screen"
        Identifier "Screen0"
        Monitor    "HDMI1"
EndSection

Section "Screen"
        Identifier "Screen1"
        Monitor    "DP1"
EndSection

Сие означает, что DP1 должен быть слева от HDMI1, а HDMI1 должен быть первичным монитором (оба монитора присоединены к одной Intel'овской видеокарте). Секцию, описывающую Screen1, равно как и упоминание о ней в ServerLayout, можно убрать — без них поведение ровно такое же.

Тем не менее, при запуске «иксов» вижу:

$ xrandr
Screen 0: minimum 8 x 8, current 3840 x 1200, maximum 32767 x 32767
DP1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 520mm x 320mm
...
HDMI1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 510mm x 290mm
...

и всё лечится либо перестановкой мониторов местами (т. е. DP1 — это по-прежнему primary, но он справа от HDMI1), либо через

$ xrandr --output HDMI1 --primary

ЧЯДНТ?

Всем привет.

Хочу научить XTerm (а) понимать и (б) различать Alt и Meta, но не очень понимаю, возможно ли (б).

Сейчас XTerm сконфигурирован так:

*.vt100.altSendsEscape:         True
*.vt100.altIsNotMeta:           True
*.vt100.metaSendsEscape:        True
*.vt100.eightBitInput:          False

-- но в этом случае нажатия Alt+Key, Meta+Key и Esc, Key интерпретируются одинаково (как escape-последовательность, соответствующая Alt+Key).

Может кто-нибудь проконсультировать?

Заранее спасибо.

Закономерно не найдя последней поддерживаемой версии (2.9.1) на AMO, полез на https://addons.thunderbird.net/en-US/seamonkey/addon/adblock-plus/, но напоролся на HTTP 404.

На официальном сайте версий для SeaMonkey тоже не нашёл, в итоге пришлось качать с https://ftp.tw.freebsd.org/distfiles/xpi/.

Что случилось? Какую серию «Санта-Барбары» я пропустил?

Собственно, вот:

https://yvoinov.blogspot.com/2018/09/google-cache.html

Всех приветствую.

Вопрос следующий.

Дано: некие глобальные настройки Xft (продублированные в fonts.conf):

$ xrdb -query | grep ^Xft
Xft.rgba:       none
Xft.hinting:    true
Xft.autohint:   false
Xft.hintstyle:  hintfull
Xft.antialias:  true
Xft.lcdfilter:  lcddefault

и настройки, индивидуальные для конкретного шрифта (в fonts.conf):

$ fc-match --verbose ':family=Courier New'  | grep -E '\<(family|antialias)\>'
        family: "Courier New"(s)
        antialias: False(s)
$ fc-match --verbose ':family=Luxi Mono'  | grep -E '\<(family|antialias)\>'
        family: "Luxi Mono"(s)
        antialias: True(w)
$ fc-match --verbose ':family=Terminus'  | grep -E '\<(family|antialias)\>'
        family: "Terminus"(s)
        antialias: True(w)
$ fc-match --verbose ':family=DejaVu Sans Mono'  | grep -E '\<(family|antialias)\>'
        family: "DejaVu Sans Mono"(s)
        antialias: True(w)

Т. е. вот здесь видно, что Courier New будет по умолчанию отрисован без AA, а все остальные кандидаты — как раз с AA.

И вот теперь я хочу, например, пресловутый Courier New отрисовать со включённым AA, но только в конкретном приложении, без изменения конфигурационных файлов:

$ xterm -fa 'Courier New:size=12:antialias=true:rgba=rgb'
$ rxvt -fn 'xft:Courier New:size=12:antialias=true:rgba=rgb'
$ stterm -f 'Courier New:size=24:antialias=true:rgba=rgb'

И нихрена — шрифт всё равно выглядит aliased, если только я не поменяю fonts.conf.

ЧЯДНТ?

То, чего я хочу, вообще возможно?

Стильно, модно, молодёжно.

Mozilla Foundation публикует победную запись в блоге: Make your Firefox browser a privacy superpower with these extensions.

И внезапно выясняется, что

With this extension, I see that for every page you load in your browser, there is a POST to http://136.243.163.73/. The posted data is garbled, maybe someone will have the time to investigate further.

Ну и развязка: Firefox Add-On With 220,000+ Installs Caught Collecting Users' Browsing History.

Где там было сравнение производительности движков? «Servo ворует ваши личные данные вдвое быстрее, чем Gecko и XUL».

Ну и, для тех, кто забыл, 2 года назад вся эта ахинея начиналась так:

More Secure Extensions

Because extensions built with the Add-on SDK can request XPCOM privileges, they could still introduce unintentional security and stability issues into Firefox. Even add-ons written by well-meaning developers can accidentally introduce vulnerabilities that could allow malicious code to execute with the full privileges of the browser. WebExtensions uses its manifest.json to mitigate this by requiring add-on authors to declare up front which permissions their code will need to operate. Unlike the Add-on SDK, WebExtensions does not allow arbitrary XUL/XPCOM access, so even insecure/vulnerable code is limited to its whitelisted subset of functionality. This vastly reduces the vulnerability surface of a WebExtension, leading to faster review times and a more stable browser.

Попробовал тут по старой памяти скрестить богомерзкий slack (стильно, модно, молодёжно, корпоративный стандарт) с Pidgin через XMPP, но увы.

Модуль для weechat (wee-slack/wee-slack) тоже не взлетел (т. е. соединяется, но не работает).

Вот ещё нашёл erroneousboat/slack-term (альфа, проект не обновлялся с апреля) и cixtor/slackapi, но их пощупать пока руки не дошли.

Какой у кого есть опыт? Поделитесь, пожалуйста.

Хочется slack-клиент, который бы не был написан на JavaScript и жрал бы меньше 1G оперативы.

Дано:

• Один пользователь, от имени которого запущены X Window
• Другой пользователь (имеющий доступ к текущему DISPLAY), от имени которого запущено некоторое GUI-приложение, показывающее оповещения через dbus. Но dbus наплевать на текущий DISPLAY.

Хочется странного: чтобы dbus-оповещения другого пользователя показывались на экране. Т. е., чтобы имело видимый эффект, например, следующее:

sudo -u ihateslack notify-send 'Заголовок' 'Текст' --icon=dialog-information

Приветствую.

По какой-то причине настройки клавиатуры внутри /etc/X11/xorg.conf:

Section "InputDevice"
        Identifier      "Keyboard0"

        Driver          "evdev"
        Option          "Device"        "/dev/input/by-id/usb-Logitech_USB_Keyboard-event-kbd"

        Option          "XkbRules"      "xorg"
        Option          "XkbModel" "pc105"
        Option          "XkbLayout" "us,ru"
        Option          "XkbVariant" ",winkeys"
        Option          "XkbOptions" "altwin:meta_win,compose:ralt,grp:menu_toggle,grp:rctrl_switch,grp:sclk_toggle,grp_led:scroll,terminate:ctrl_alt_bksp"
EndSection

не работают должным образом (ну, т. е., не включается переназначение Meta на Win, игнорируется Ctrl+Alt+Backspace и т. д.), так что приходится всё дублировать в ~/.xinitrc:

setxkbmap -option
setxkbmap -option altwin:meta_win
setxkbmap -option compose:ralt
setxkbmap -option grp:menu_toggle
setxkbmap -option grp:rctrl_switch
setxkbmap -option grp:sclk_toggle
setxkbmap -option grp_led:scroll
setxkbmap -option terminate:ctrl_alt_bksp

В логе на старте виже следующее (т. е. «клавиатур», похоже, было найдено куда больше, чем я просил):

( (простыня) )

Ну и в том же самом логе многократно в процессе работы:

[2021148.899] (II) input device 'Power Button', /dev/input/event6 is tagged by udev as: Keyboard
[2021148.899] (II) input device 'Power Button', /dev/input/event6 is a keyboard
[2021148.900] (II) input device 'Video Bus', /dev/input/event16 is tagged by udev as: Keyboard
[2021148.900] (II) input device 'Video Bus', /dev/input/event16 is a keyboard
[2021148.900] (II) input device 'Power Button', /dev/input/event4 is tagged by udev as: Keyboard
[2021148.900] (II) input device 'Power Button', /dev/input/event4 is a keyboard
[2021148.901] (II) input device 'Sleep Button', /dev/input/event5 is tagged by udev as: Keyboard
[2021148.901] (II) input device 'Sleep Button', /dev/input/event5 is a keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event1 is tagged by udev as: Keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event1 is a keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event2 is tagged by udev as: Keyboard
[2021148.902] (II) input device 'Logitech USB Keyboard', /dev/input/event2 is a keyboard
[2021148.903] (II) input device 'Logitech Logitech USB Headset', /dev/input/event0 is tagged by udev as: Keyboard
[2021148.903] (II) input device 'Logitech Logitech USB Headset', /dev/input/event0 is a keyboard
[2021148.904] (II) input device 'ACPI Virtual Keyboard Device', /dev/input/event20 is tagged by udev as: Keyboard
[2021148.904] (II) input device 'ACPI Virtual Keyboard Device', /dev/input/event20 is a keyboard

Как можно дальше продиагностировать это поведение?

Хочется однократно задать настройки клавиатуры для всех пользователей, а не носить ~/.xinitrc туда-сюда.

Если экземпляр BasicDataSource из Apache commons-dbcp (версии 1.4, т. к. я ограничен Java 1.6) сконфигурирован с defaultAutoCommit=false, то библиотека выполняет два идиотских ROLLBACK'а — один при взятии соединения из пула, и ещё один при возвращении его обратно (т. е. закрытии соединения из пула при сохранении низкоуровневого физического соединения открытым).

Соответствующие стек-трейсы (на примере T4CConnection драйвера Oracle Thin):

T4CConnection(PhysicalConnection).rollback() line: 1950	
PoolableConnection(DelegatingConnection).rollback() line: 368	
PoolableConnectionFactory.passivateObject(Object) line: 685	
BasicDataSource.validateConnectionFactory(PoolableConnectionFactory) line: 1559	
BasicDataSource.createPoolableConnectionFactory(ConnectionFactory, KeyedObjectPoolFactory, AbandonedConfig) line: 1545	
BasicDataSource.createDataSource() line: 1388	
BasicDataSource.getConnection() line: 1044	

и

T4CConnection(PhysicalConnection).rollback() line: 1950	
PoolableConnection(DelegatingConnection).rollback() line: 368	
PoolableConnectionFactory.passivateObject(Object) line: 685	
GenericObjectPool.addObjectToPool(Object, boolean) line: 1379	
GenericObjectPool.returnObject(Object) line: 1342	
PoolableConnection.close() line: 90	
PoolingDataSource$PoolGuardConnectionWrapper.close() line: 191	

Т. обр., каждая успешная транзакция — это последовательность след. вида:

1. ROLLBACK
2. полезная работа с БД
3. COMMIT
4. ROLLBACK

(вместо единственного COMMIT'а), в то время как каждая неудачная — это:

1. ROLLBACK
2. полезная работа с БД
3. ROLLBACK
4. ROLLBACK

(вместо единственного ROLLBACK'а).

Вышеописанное поведение даёт дополнительную нагрузку на redo- и undo-подсистемы (что очень хорошо видно под нагрузкой в Oracle, но, на самом деле, при использовании commons-dbcp проблема универсальна — я наблюдал ровно то же самое для MySQL).

Вопрос 1: как избавиться от пресловутых ROLLBACK'ов, сохранив экземпляр DataSource сконфигурированным с defaultAutoCommit=false (т. е. без необходимости вручную вызывать setAutoCommit(false) для каждого соединения, взятого из пула)?

Вопрос 2: как можно обойти проблему средствами Oracle (т. е. без необходимости менять прикладной код или библиотеки)?