Qual a melhor interface a ser utilizada se eu tenho uma coleção muito grande( + de 100 mil registros ), sendo que cada registro é um bean de 30 atributos ?? Estou perguntando isso porque estou preocupado com esses registros todos em memória.
Observações:
1)Não é necessário estar sincronizado
2)Os beans já irão ser adicionados ao objeto de maneira ordenada.
3)A coleta dos dados da collection sempre se dará na mesma ordem de inserção( não existirá preocupação com sort ).
Obrigado.
Acho que qualquer um que use a interface List poderia ser utilizado… como um ArrayList… agora com esta porrada de objetos na memoria… vc tem ctza que realmente é necessario manter todos estes beans na memoria? não tem como fazer paginação? creio que a paginação seria a melhor opção… mas pode ser que estes registros tenham que ficar em um relatorio pdf, txt, xls ou seila o que e não podem ser paginados eu não sei…
LinkedList que tal?
LinkedList = aceita duplicata e a ordem de iteração é por inserção.
O ArrayList atende todas as suas necessidades.
O problema é que o meu projeto é JAVA/COBOL, isto é, o COBOL me traz 250 ocorrências de cada vez, caso tenha mais que 250 eu chamo o COBOL novamente até que não haja mais registros. O sistema já está sendo testado em ambiente de homolocação, e como eles tem muito mais registros que em ambiente de desenvolvimento eles estão encontrando problemas( não sei aonde ) informando que o processo está ficando em loop. A equipe de COBOL( que desconhecem completamente JAVA ) está informando que o JAVA está re-chamando o COBOL passando sempre as mesmas informações, porém a única maneira de isso acontecer seria:
O que vcs acham ???
Com relação ao que o luistiagos falou, eu preciso guardar tudo porque somente depois que o COBOL retorna todos os registros eu pego esta collection e jogo em uma TreeView( árvore ), que não deveria estar sendo utilizada para tantos registros, pois a renderização disso é péssima.
Vejamos… se seu bean tiver 30 atributos de 32 bytes, serão 960 bytes por bean.
Se você tiver 300.000 registros: 288.000.000 bytes ou 274MB.
Tem certeza que isso é muito? Ponha uma máquina de 2GB de ram e configure o Java para poder ocupar todo esse espaço. Uma boa política é também não carregar tudo na TreeView.
Outra coisa: procure só carregar na tree view os nós que forem abertos.
Outra opção é também repensar na arquitetura desse sistema. É impossível que um usuário consiga visualizar 300.000 registros.
Nem alguém com MUITA boa vontade não faz isso. Converse com os coboleiros e explique que o Windows é inferior ao OS/390… e então, reestruture o sistema para carregar só dados mais úteis.
Na pior das hipóteses, use um processo para criar uma pequena base intermediária (um buffer no disco do micro), e então use essa base para leitura.
Momento nostalgia: Esse dragão desenhado na capa do D&D original, ainda da TSR, me traz boas lembranças. 
Se não é o mesmo, lembra muito.
[quote=marcosbrandao]O ArrayList atende todas as suas necessidades.
[/quote]
também acho
É verdade ViniGodoy, eu também acho que a TreeView não é o componente ideal para se visualizar tantos registros, eu sugeri aos Analistas que colocassem alguns campos de filtros obrigatórios para que a TreeView ficasse mais leve porém no momento a idéia ainda não foi aprovada pelo Cliente. Realmente seria melhor abrir somente os nós abertos, porém o componente TreeView que nós utilizamos é do Cliente e ela não tem suporte a esse tipo de implementação, e não podemos utilizar outra TreeView pois teria que ser homologado pelo Cliente( o que levaria muito tempo ).
Vou tentar simular o ambiente de Homologação aqui em Desenvolvimento para ver se o problema é realmente esse( de memória ), mas tenho certeza que não é, acredito firmemente que o problema é na renderização da página.
Não me lembro de onde peguei esse dragão, fiz uma busca no Google e acabei gostando da imagem, nem sabia que era do D&D.
Valeu.
Bom, então é torcer para essa “burrocracia” do processo de vocês entender o erro e resolver o problema o mais rápido possível… enquanto isso, a lentidão joga o dinheiro do cliente pelo ralo…
É por isso que eu gosto de XP. Você já ligaria para o cliente e falaria direto com ele.
Mas fazer o que… é importante jogar com as regras do jogo…
procure carregar cada no por vez… tipo se x no é selecionado requisite ao cobol estes valores do nó x que o usuario selecionou… não carregue tudo de uma só vez na treeview… tente carregar primeiramente só os nós e depois carregar os filhos qdo o usuario selecionar o nó desejado… sobre isto da garbage collection estar colletando os objetos do seu list ou seu list não aguentar o tranco… isto não existe… seu list so não ira aguentar o tranco qdo a memoria da sua VM for pro pau… dai vc recebera um OutOfMemoryError por falta de memoria da VM… para que isto não ocorra facilmente tente expandir o maximo que puder a memoria da VM para ela “aguentar o tranco” e não se preucupe com a garbage collection… ela não esta limpando seu list… pois o tempo não interfere nela o que interfere nela é quando ela não acha mais a referencia de um objeto… ou vc setando ele com null ou vc sobscrevendo esta referencia com a referencia de outro objeto… dai a referencia que foi sobscrita pela outra fica perdida sem nenhuma instancia apontar pra ela… dai sim ela e coletada pela vm… o tempo dos objetos na memoria não interfere em nada… o que pode estar acontecendo tbm é vc estar passando os mesmos parametros sem na pesquisa de novos registros pro cobol ou o cobol estar processando sempre o primeiro parametro que vc passa a ele… tente debugar e verificar a cada chamada do cobol que parametros estão sendo passados… se vc não esta passando os mesmos sempre… se não for isto nem esquente a cabeça que o problema e com os cobolzeiros…
Valeu pessoal, obrigado pela ajuda.