Я так понимаю что задача сводится к нахождению всех листовых узлов дерева объектов. А может попробовать грамотно запрос на JPA написать, который их находить будет?

Hroft:
В Java менеджер памяти заменить, к сожалению, впрямую нельзя (ограничения безопасности). Есть объекты-ссылки, позволяющие в какой-то степени разрулить ситуацию, когда памяти не хватает, но если полагаться на fetch=FetchType.EAGER в JPA, то пристроить эти объекты оказывается уже некуда. Может быть (и даже более вероятно), не StackOverflow, а OutOfMemory, но... с точки зрения результата - невелика разница. :( Мне памяти-то доступно метров, может, двадцать. А когда на листьях оказываются объекты размерчиком эдак по килобайту, и их несколько тысяч... а теперь представьте, что эту же структуру из базы дёргают ещё два-три хотя бы потока (а их будет не два-три)... и всё, "приплыли", как говорится.
Веб-приложение, чтоб его. :-\

powerOn, типа того, но не совсем. Мне бы количество узлов в конкретной ветви дерева найти. Листья-то что - запрос вроде вот этого, и всё:
Можно, конечно, извратиться и использовать вложенный запрос, но зачем? - и так сработает.
А вот как посчитать количество вообще всех потомков конкретного узла - это вопрос...

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

Это сообщение отредактировал(а) Hroft - 23.9.2008, 10:58

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

Действительно, мысль интересная. В принципе, попробовать ничто не мешает, хотя при этом в промежутке между обновлениями индекса пользователь будет получать недостоверную информацию (кстати, проверено - часто такую прогу не позапускаешь, во время анализа загрузка процессора растёт очень сильно, а снижать приоритет потоку - так он работать будет дольше желаемого). Ещё можно всё-таки сделать рекурсию в самой программе, но дёргать только ID объектов базы, а не сами объекты. Возни чуть больше, но зато в память укладываюсь, особенно если обернуть их в PhantomReference. Плюс - ID выбирается шустрее, чем сам объект, что тоже очень приятно. А количество прямых потомков узла при этом определяется автоматически - по длине результирующего списка. Не так уж сложно. "Дёрнуть" из базы после этого связанную сущность по какому-либо критерию тоже не проблема, QL-запросам можно же коллекции в качестве параметров передавать?