Сергей Тарасов:
Так оффтопика и нет - все к тому, что: "...Скорость - не проблема, как Вы могли бы подумать...", а жалобы и наезды, зачастую, от неправильного использования и плохого понимания. Это как писать однопоточный броузер, не думая о том, что когда поток ждет данные от сервера, окно даже отрисовать некому будет.

С большим интересом посмотрел на программу, о которй говорил Алексей Казанцев. Эффект действительно потрясающий - вместо максимум секунды, за которую Билдер отрисовывается при таскании над ним WinAmp'a, он сдыхает и очень конкретно. Явный глюк в реализации jdk: то же самое происходит с любым swing-приложением (вплоть до текст+кнопка) и почти все время проходит в native методах. Хорошо, что в жизни таких окон почти не бывает. Для тех, кто эту программу не видел - она может нарисовать окно с большим количеством дырок и любой формы.
Спасибо Алексею, а выводы, я думаю, каждый будет делать самостоятельно.

Александр Киреев
Что-то я уже и нить потерял наших споров. Завязываю с оффтопиком. Кстати, потоки создаю не я, а ORB.

Lamer:
>Молодой человек. Обратите внимание, как у Borland'а реализован MIDAS-
>server.
А вы, любезнейший, обратите внимание на то, что другие говорят. Я обсуждаю то, что вы написали, а детали реализации Борландом MIDAS сервера меня сейчас не интересуют. Далеко не все коммерческие продукты являются хорошими примерами для подражания. Если вы считаете, что _ваш_ способ очень хорош - поделитесь опытом. Мы для этого и общаемся. Но желательно побольше деталей - облегчает дискуссию.

>Существует технология раздельной обработки запросов(и ответов)
>пользователей.
>Прежде, чем что-либо говорить, подумайте сначала. Или Вы считете,
>что умнее, чем разработчики Borland'а?
У того же Борланда чудный Interbase сервер содздает новый _процесс_ для каждого имеющегося соединения - вы считаете это их большим достижением?

>А насчет работы Java со строками... Попробуйте - увидите. Лучший
>ответ - это реальный тест (а не голословные утверждения).
Тогда хочется увидеть кусок кода, который 10 секунд добавляет 1000 строк в List. Иначе это ваши утверждения являются "голословными".

Александр Киреев
>А где ООП? Клиент - объект сервера, но он не "is a" поток/процесс. Права клиента и другие правила должны быть в сессии, не лежать локальными данными в сессии.
А кто говорил, что он и есть поток? Ассоциировать поток означает только, что тот выполняется от имени и с правами данного субъекта. Внешне это может быть и просто вызов метода объекта "Пользователь". Права не могут, как вы выражаетесь "лежать в сессии", так как они динамические и вычисляемые.

>Для чего, например, буферизуются потоки - чтобы понты поколотить или для дела?
Нет, не для "понтов" ;-) а для того, чтобы не выделять память при каждом обращении к потоку.

>Я как раз и говорил о _лишней_ синхронизации.
Синхрониация не бывает, ка вы говорите, "лишней". Она или нужна, или нет.

to Александр Киреев

Молодой человек. Обратите внимание, как у Borland'а реализован MIDAS-server. Выдержка из help'a:

1. Internal: The remote data module is created in an in-process server. Choose this option when creating a remote data module as part of an active Library (DLL).
2. Single Instance: Only a single instance of the remote data module is created for each executable. Each client connection launches its own instance of the executable. The remote data module instance is therefor dedicated to a single client.
3.Multiple Instance: A single instance of the application (process) instantiates all remote data modules created for clients. Each remote data module is dedicated to a single client connection, but they all share the same process space.

Существует технология раздельной обработки запросов(и ответов) пользователей.
Прежде, чем что-либо говорить, подумайте сначала. Или Вы считете, что умнее, чем разработчики Borland'а?

А насчет работы Java со строками... Попробуйте - увидите. Лучший ответ - это реальный тест (а не голословные утверждения).

Сергей Тарасов:
>Ну хотя бы для того, чтобы проверить права субъекта,
>ассоциированного с данным процессом. Или некие правила выполнения
>(динамически вычисляемые).
А где ООП? Клиент - объект сервера, но он не "is a" поток/процесс. Права клиента и другие правила должны быть в сессии, не лежать локальными данными в сессии.

>Если 50 пользователей начнут одновременно писать в один
>неразделяемый ресурс, то почему бы мне не создать 50 потоков и все
>заботы по управлению возложить на ОС?
Если у вас сверхмощное железо - пожалуйста, но тогда не стоит говорить о производительности, а точнее о ее отсутствии. В противном случае надо что-то и самому сделать. Я уверен, что ни один (нормальный) web или ftp сервер не создает _новый_ поток для каждого запроса. Почему они не хотят все заботы возложить на ОС? Может потому, что она и не должна решать все вопросы? Для чего, например, буферизуются потоки - чтобы понты поколотить или для дела?

>Речь, конечно, уже не о жабе. Я не понял, зачем мне бороться
>с "дорогостоящей операцией синхронизации", если это привилегия ОС?
Почему все используют алгоитмы типа quick sort, а не сортируют пузырьком? Может для того, чтобы избежать лишние операции? Я как раз и говорил о _лишней_ синхронизации.

>А пул... Я понимаю, нужен динамический пул, например, чтобы
>поддерживать несколько соединений с БД (через одно все не
>протиснутся). А зачем пул, чтобы управлять созданием потоков только
>ради того, чтобы избежать выделения дополнительных ресурсов ОС
>(подразумеватся, что сервер расчитан на предельные нагрузки)?
Почему же не открывать новое соединение с БД на каждый запрос? Это же не наши проблемы - пусть другие мучаются. Пул и нужен, чтобы избежать выполнение лишних опреаций программой _и_ ОС. Ваш сервер не сможет физически потянуть более 100 клиентов - поставьте размер пула на 100 потоков - и ресурсы сэкономите, и ограничите максимальную нагрузку, тем самым обеспечив quality of service.

Александр Киреев
>Вот он и глюк - зачем вам ассоциировать процесс(?) или поток с пользователем. У пользователя может быть сессия, но это данные, а не способ их обработки.
Ну хотя бы для того, чтобы проверить права субъекта, ассоциированного с данным процессом. Или некие правила выполнения (динамически вычисляемые). Сессии - это не процессы, они могут спокойно лежать в виде ID в пуле и ждать своего часа. Если 50 пользователей начнут одновременно писать в один неразделяемый ресурс, то почему бы мне не создать 50 потоков и все заботы по управлению возложить на ОС?
>Чего именно вам не хватает в Жабе? Может я что-то пропустил, но о реализовывать руками речь по-моему не шла.
Речь, конечно, уже не о жабе. Я не понял, зачем мне бороться с "дорогостоящей операцией синхронизации", если это привилегия ОС?
А пул... Я понимаю, нужен динамический пул, например, чтобы поддерживать несколько соединений с БД (через одно все не протиснутся). А зачем пул, чтобы управлять созданием потоков только ради того, чтобы избежать выделения дополнительных ресурсов ОС (подразумеватся, что сервер расчитан на предельные нагрузки)?

Сергей Тарасов:
>>У пользователя своя критическая секция - уже смешно.
>Лично у пользователя нет, но у процессов, ассоциированных с данными
>субъектами - есть.
Вот он и глюк - зачем вам ассоциировать процесс(?) или поток с пользователем. У пользователя может быть сессия, но это данные, а не способ их обработки. Или мы до сих пор занимаемся процедурным программированием?

>И я все-таки не понял, почему нужно реализовывать руками то, что по
>идее является часть нормальной ОС.
Чего именно вам не хватает в Жабе? Может я что-то пропустил, но о реализовывать руками речь по-моему не шла.

Александр Киреев
>У пользователя своя критическая секция - уже смешно.
Лично у пользователя нет, но у процессов, ассоциированных с данными субъектами - есть.
И я все-таки не понял, почему нужно реализовывать руками то, что по идее является часть нормальной ОС.