"Организовать очередь. Т.е. поток помещает в результат в очередь и тут же завершается, а далее отдельный трэд потихоньку вытаскивает элементы из очереди и кладет в БД."

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

Любой сбой в очереди, при общении с самой базой, может потребовать неоднозначной реакции в зависимости от причин сбоя, важности данных и, главное, насколько сам поток готов к обработке такого сбоя и не зависит ли это от времени сбоя.

Запись пакетов данных, конечно лучше чем одиночная, но и любой сбой в пакете потребует четко продуманной логики дальнейших действий. В общем и целом, устойчивости системе это не добавит.

Я не знаю как обстоят дела с Postgress, но в том же Oracle не так просто получить проблемы с производительностью чтобы это начало сказываться на приложении - вы уверены, что у вас так много потоков и так часты запросы на обновления, что это РЕАЛЬНО приведет к деградации производительности СУБД?

В общем-то вариант я не отвергаю, но при важных данных я бы рассмотрел вариант synchronized метода в отдельной триаде, пишущего на локальный диск (циклическая очередь из двух-трех файлов), т.е. имеем своеобразную самопальную транзакционную систему. Легко масшатабируется возможностью запуска нескольких триад.
К этим файлам цепляется демон, который читает данные из локального файла/ов и пишет в базу пакетами. (Думаю хватит одного).

Вариант не намного отличающийся от пула соединений, но переносит немалую часть нагрузки на клиента, возможно это будет более приемлемо.

cooluser2 carper

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

Вроде как при таком подходе будет гарантия сохрания данных, ну конечно если JVM не упадет.


Увы, гарантию может дать только сама база. :)
Если сохранность данных не столь важна, то, разумеется, можно передавать данные в буфер сервисного потока (можно нескольких, в тяжелых случаях), который единообразным способом пытается их записать.
Я бы дополнительно сделал эти данные адресными, снабдив каждую строку в буфере GUID потока, их туда пославшего.

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

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

Опять же, я не знаю особенностей Postgresql, но Oracle умеет решать эту проблему - она как раз использует и демоны и запись во временные файлы и их очередь.
Т.е. стоит ли городить огород, чтобы своими силами реализовать то, что уже есть?

Если количество потоков (точнее частота записи) нешуточное, то непрерывно что-то дергать в базе, действительно, варварство, а если нет, то может ну его?

P.S.
В принципе, я бы тут думал не над техническим решением, а над тем почему надо писать в базу столько данных, что она начинает аж захлебываться, причем не очень важно чтобы записались все данные.
Что-то тут не так. Может быть нужны какие-то краткосрочные тренды, для вывода оперативной информации с совсем даже не частой записью некоторых итоговых, усредненных, или как-то еще обсчитанных, данных?
Зачем вам тысячи и миллионы строк, для которых даже не очень важно все ли они записаны?
Что вы с ними дальше-то делать собираетесь?
Очевидно, что просматривать их никто не будет, будут делаться какие-то обобщающие выборки.