Ok Chiappa, vou tentar levantar se o JBoss tem algum tipo de timeout para as transaçoes, pq penso que o Oracle não deve estar respondendo as transações em tempo hábil, assim o JBoss encerra a transação e utiliza a mesma transação para outro usuário, consequentemente "travando" o processo servidor. Em um teste feito, matando o processo servidor pelo sistema operacional o processo servidor "libera" o processo e o pmon inicializa outro processo servidor que opera normalmente até algum momento.
Agradeço sua ajuda. Abraços Leandro --- Em oracle_br@yahoogrupos.com.br, "jlchiappa" <[EMAIL PROTECTED]> escreveu > > "Utilizo MTS para JBoss para controlar a quantidade de acessos ..." - > não colega, a funcionalidade ** BÁSICA ** de um pool de conexões é > atender mais usuários do que conexões disponíveis, o que ele faz ,se > corretamente configurado, temporariamente "desconectando" algumas (as > mais antigas sessões normalmente) ou algo similar, para que essas > conexões atendam os outros usuários a mais, a idéia básica é que uma > conexão do banco atenda n sessões conectadas ao pool, uma por vez. > ORA, até onde entendo *** de forma alguma *** vc tem que ter > esse "rodízio" de sessões no banco, que é o que o MTS /shared server > faz, esse rodízio JÁ DEVERIA ESTAR sendo feito pelo pool externo, > essa é a utilidade dele !!!! > Quanto à documentação, no metalink, na nota de Subject: What is > STATUS column in the V$SHARED_SERVER? Doc ID: Note:99217.1 o status > está documentado, basicamente ela diz o que eu disse na msg anterior, > ou seja, o shared server está "dedicado", está esperando por resposta > à uma "mensagem", à uma comunicação, e logicamente essa resposta VAI > SER por parte do dispatcher, que é quem faz a "ponte" entre o shared > server e o processo cliente, mas que dá a resposta é o processo > cliente.... Eu estou teorizando, quanto ao porque, que a carga está > aumentando, o pool jboss, como é a sua função, quer re-usar a > conexão que atendeu ao processo cliente x pra atender outro processo > y, assim x foi "desconectado", e o pool o está fazendo antes que x > tenha a chance de dar pro mts a msg de "atendimento completo", assim > o shared server mts fica esperando resposta de x, que nunca vai > receber, e fica bloqueado.... ==> Para mim , inclusive, é POR ISSO > que em teste/desenvolvimento conexão "poolizada" com MTS funciona, no > teste/desenvolvimento o ambiente não está sob pressão, não ocorre o > caso do pool externo "desconectar" uma sessão x antes que ela tenha > tido o tempo de enviar msgs de sucesso para o shared server..... > Então pra mim o teu problema decorre disso, se vc quer usar um pool > externo, DEIXE O POOL EXTERNO controlar as sessões - todo e qquer > pool de conexões digno do nome TEM uma config de quantas sessões > físicas no máximo vão ser mantidas no banco, quantas são abertas > assim que o pool starta, é o trabalho ** dele ** re-usar as > conexões..... Não tenho aqui nenhum tipo de pool externo pra poder > exemplificar/testar, tudo o que eu disse é derivado do meu > entendimento, MAS acho que faz sentido a possibilidade.... > > => Então para a "idéia" que vc perguntou se alguém tem, essa é a > minha, vc a testará aí, blz ? > > []s > > Chiappa >
