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

Но тут есть несколько проблем:
1. В общем случае, запрос к базе прерван быть не может (во всяком случае, на стороне сервера он отработает до конца, а вызывающий метод будет ждать результатов), а поскольку все эти запросы почти наверняка намного медленнее, чем запуск потоков их использующих, то прервать поток можно только на этапе fetch и возможной постобработки уже готовых результатов.

2. Правильно спроектированный пользовательский интерфейс (я сейчас не про отчетную форму), не должен заставлять ждать своего появления на экран больше 3-5 секунд. Если принять, что вы хотите ускорить самую медленную операцию, а именно, выборку из базы данных, то получаем, что макс. время зависит от самого медленного обращения к базе (предположим, что все запросы выполняются параллельно).
Таким образом, эта, самая медленная, операция не должна занимать больше 3-5 секунд. Тогда наихудшее время отклика на возможную ошибку не превосходит этих 3-5 секунд.
Не проще ли в таком случае дождаться выполнения всех потоков и по их завершении просто рассмотреть не завершился ли хотя бы один с ошибкой?

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


P.S. В JAVA нет такого понятия как указатель.

jet8
Данные потупают с application сервера в виде xml. Натолкнулся на то, что иногда xml-ник приходит битый, вот тут и надо что-то предпринимать - либо пытаться инициализировать форму по-новой, либо выгружать приложение.


Замечание не совсем по делу, но не могу удержаться:
Приход битого xml - это серьезная проблема, с которой срочно надо разбираться (и это проблема совсем не вашей бедной JAVA программы), т.к., в общем случае, возможен самый страшный вариант - приход битого xml замаскированного под небитый, например, со слегка перевранной цифрой. Не говоря уж про то, что application server, выдающий битые файлы - это ЧП и попытка обойти это на клиенте столь же разумна, как лечение гангрены путем завязывания пациенту глаз - чтобы не видел, что у него там. :)

OU
Может, в зависимости от RDBMS (крупные RDBMS типа MS SQL или Oracle эту фишку поддерживают).


Можно? только применительно НЕ к Statement, а к SQL PLUS или там PL/SQL показать реализацию такого прерывания для Oracle?
Т.е. я точно знаю, что в том же SQL PLUS есть такая возможность, но никак не могу вспомнить как это выглядит в виде команды/процедуры?

Помню, что что-то такое давно пытался делать (сильно подозреваю, что что-то на С мутил), но фишка была в том, что Oracle слушался далеко не всегда, т.е. иногда просто игнорировал, а иногда возвращал управление, но процессор и диск продолжал грузить задачей.



--------------------------
Кстати, если я правильно понимаю, то даже если такой метод для Statement и сработает, то понадобится отдельный поток, который должен вызвать cancel (ну не полагаться же на stmt.setQueryTimeOut), т.к. тот поток, который выполняет query, выполняет блокирующий метод.

Т.е. понадобится доп. поток (в идеале один, если организовать диспетчер принудительного завершения потоков), который будет принимать запрос от "аварийного" потока на закрытие запросов инициированных другими потоками.
Причем ourStatement.cancel() - в свою очередь, блокирующий метод? (или нет?).
Думаю, что такое усложнение в данном конкретном случае не совсем оправдано. Вот если мы городим форму отчетности, то это имеет смысл, причем большой. :)


По поводу XML, проблема может состоять в типе протокола который вы используете для связи с сервером (UDP или HTTP/TCP).

Использовать UDP для получения значимых данных, да еще с последствиями в виде неверного парсинга xml?
Не думаю, что такое разумно.



P.S. "использование Callable interface" - это ведь только с SE 5.0 есть?

expp
и откуда берётся xml?


XML берется как универсальный формат передачи данных легко проламывающийся через все ограничения PROXY и платформы.
Поскольку за все приходится платить, то в 90% случаев он и нафиг не нужен, зато создает излишнюю нагрузку на клиента и сервер. :)
Зато модно. :)


и на кой ляд вам толстый клиент? (причины?)

Можно уточнить, что вы понимаете под "толстым" коиентом?
Классический вариант, когда большинство обработки информации идет на клиенте или современный , когда на откуп клиенту отдано отображение информации и весьма небольшая часть бизнес правил, ответственная за контроль правильности ее ввода информации (только та, которая повышает usability, не затрагивая проверку коррекности данных на сервере)?
Чуствую, что написал непонятно, но сейчас почему-то часто "толстым" обзывают даже тех весьма поджарых клиентов, которые не считают нормальным предоставлять интерфейсную часть в виде убогих HTML формочек, рассчитанных на сферического среднего пользователя Интернет.
:)


jet8
Тем более что в конструкторе у меня просто вызывается метод, который и стартует потоки инициализации.

По-хорошему, форма не должна напрямую лезть к модели, ей должно быть фиолетово, что там и почему вызывается, пусть контроллер обратится за данными к модели, и, в завимости от результата, выдаст ту или иную форму. :)
Но частенько из сладкой тройки MVC, устраивают сладкую парочку M+ VC.
Особого преступления здесь зачастую нет.

OU
a коммандно что то типа system kill session (session id)

Неа, что-то типа alter system kill session '286,9195', разумеется, убьет и запрос, но такое ощущение, что SQL PLUS делает это иначе, т.к. ,даже если он маскирует сообщение системы и перелогинивает пользователя в автоматическом режиме, то что-то это у него получается феерически быстро.

expp
туда же: я лична зарёкся трактовать MVC, где у него, что по-моему никто не знает.


Не знаю, я бы попробовал так:
Давайте, например, возьмем простейшую страничку, html или там jsp с формочкой или просто ссылкой.
Даванем на ссылку (скажем запросим ФИО какого-нибудь поэта), далее возможны два пути:
Путь A.
1. Со странички запросим базу данных, не важно грубо через select или через n-промежуточных слоев. Главное, что мы конретно указали что-то нам нужен конкретный результат, причем не просто, мол хотим ФИО, а придется написать типа select FIO form myaddress (или более общий запрос, хотя сам SQL и так вполне себе абстрактный язык);
2. Получим результат, сами обработаем ошибки, сами занесем данные в атрибуты и вызовем новую форму, которая должна знать, что делать с этими данными.

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



Путь B.
1. Сообщаем классу-контроллеру, что у нас нажата ссылка.
2. Контроллер обращается к базе (опять же напрямую, или через n слоев) - уже он, а не форма, говорит, что ему нужно.
3. Он получает запрошенную информацию и вызывает новую jsp/html страничку, в зависимсти от необходимого результата (например, error.jsp).

Что же дает второй вариант?
1. Один контроллер может обслуживать сколько угодно страничек и изменения, в случае чего, можно вносить только в одном месте.
2. Страничку можно ваять не заботясь о какой-то там JAVA, что ей надо когда из себя отфорвардить и как чего закодировать, а сосредоточиться только на интерфейсе, априори будучи уверенным, что все нужные данные появятся как по волшебству. :)
3. Код всего приложения приобретает больше возможностей для параллельной разработки, когда скажем web дизайнер не ждет JAVA программиста и наоборот.
4. Возможно введение диспетчера контроллеров, который может распределять нагрузку между контроллерами и использовать разнородные контроллеры.

Ну, где-то так, извиняйте ежели что не то сказал. :)


>причём здесь JDBC Statement - как я понял у него xml транспорт и потоки >сервлет, а не RDBMS
Не причем, просто сначала было не ясно (см. первоначальный вопрос), а потом возник шкурный вопрос - как прервать запрос к Oracle без убийства сессии? :)


> carper вы с jet8 - sweet pair, что ли? кто за кого отвечает?
Нет уж, я вообще отвечать ни за кого не люблю, даже за себя. :)