Pessoal, tenho o seguinte cenário: Alguns desenvolvedores implementaram uma solução que utiliza SOA (serviços). Os serviços são implementados através de EJB´s (java) e fazem requisições SQL pequenas (sql´s simples e rápidos para o sgbd processar).
A partir desses serviços foi implementado uma solução batch que faz muitas (muitas mesmo!) chamadas dos serviços java. O banco, portanto, é inundado com chamadas sql pequenas e demora a responder para os usuários "online". A solicitação de novas conexões ao banco tbm. é grande qdo. o processo batch é executado (mesmo que a infra EJB utilize pool de conexões. Me parece que n threads java são executadas concorrentemente). Na minha opinião a solução mais indicada seria desenvolver o processamento batch através de uma stored procedure e controlar o consumo de recursos através do pacote dbms_resource_manager; Esquecer um pouco do "purismo arquitetural" que alguns defendem! Vcs. concordam? Independente disso, não estou conseguindo convencer os analistas dessa minha opinião (discussões técnicas estão sendo improdutivas!). No cenário atual estou tentando melhorar um pouco a parte que me compete (o banco). Ainda não testei, mas, será que no cenário exposto (muitas requisições sql pequenas eventualmente em paralelo/várias solicitações de novas conexões) uma configuração baseada no dbms_resource_manager amenizaria o problema? Minha preocupação é que a aplicação batch acabe "abendando" ou inundando o listener com pedido de novas conexões! Ainda não estudei a fundo a arquitetura que os desenvolvedores estão utilizando, mas, me parece que algumas partes do processamento são submetidas em paralelo ao banco pela infra java (várias threads todas processando requisições de forma concorrente). Eliandro. OBSERVAÇÃO: A ITAIPU esclarece que, por força de seu Estatuto, a presente mensagem não implica a assunção de obrigações em seu nome. [As partes desta mensagem que não continham texto foram removidas]
