Este artigo foi anteriormente publicado aqui.Hoje vou deixar uma dica rapida, como listar as sessoes ativas no oracle, isto e, os usuarios que estao conectados atraves de alguma aplicacao cliente. O sql a seguir lista todas as sessoes ativas excluindo os processos do proprio oracle.SELECT s.username, s.osuser, s.sid, s.serial#, p.spid, s.status, s.machine, s.program, TO_CHAR(s.logon_Time,'DD-MON-YYYY HH24:MI:SS') AS logon_time FROM v$session s inner join v$process p on s.paddr = p.addr WHERE s.status = 'ACTIVE' and s.type <> 'BACKGROUND'Com a lista de usuario em maos, podemos optar por "matar" a sessao de algum usuario ativo. Para isso basta executar o comando abaixo, substituindo o "sid" e "serial#' pelos valores retornados da consulta anterior. ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE; Por hoje era isso. http://imasters.com.br/artigo/20380/java/heranca-x-composicaoHa algum tempo, heranca era considerada a ferramenta basica de extensao e reuso de funcionalidade. Qualquer linguagem que nao possuisse o conceito de heranca nao servia para nada. Atualmente, todos os artigos sobre padroes de projeto desaconselham a utilizacao de heranca.E agora?Um principio basico de padroes de projeto e dar prioridade a composicao, preferir sempre tem-um ao inves de e-um. Quanto a heranca, deve ser utilizada com muita prudencia e em pouquissimas situacoes.Uma das poucas certezas que temos no desenvolvimento de aplicacoes e que existirao alteracoes. Portanto, a utilizacao de heranca para fins de reutilizacao nao da tao certo quando se tratam de manutencoes nos codigos ja existentes.Supondo que utilizamos uma classe pai para encapsular o comportamento de algum objeto. Dessa forma, todas as nossas classes filhas herdarao esses comportamentos. E o problema ocorre quando alguma das classes filhas nao precisam de algum dos comportamentos que estao encapsulados. Passamos a ter que mudar o codigo na classe filha para que o metodo que foi herdado funcione da maneira especifica para esse objeto. Ou, pior ainda, quando esse objeto nao necessitar desse comportamento, entao teriamos que sobrescrever o metodo para que ele nao faca nada.Alguns dos problemas dessa implementacao e que o encapsulamento entre classes e subclasses e fraco, e o acoplamento e forte. Assim, toda vez que uma superclasse for alterada, todas as subclasses podem ser afetadas. Perceba que estamos violando o principio basico de OO (Alta Coesao, Baixo Acoplamento).Ainda com heranca, a estrutura esta presa ao codigo, e nao pode sofrer alteracoes facilmente em tempo de execucao, fazendo diminuir a capacidade de polimorfismo.Quando utilizamos composicao, instanciamos a classe que desejamos dentro de nosso codigo. Dessa forma, estamos estendendo as responsabilidades pela delegacao de trabalho a outros objetos. Em vez de codificar um comportamento estaticamente, definimos pequenos comportamentos padrao e usamos composicao para definir comportamentos mais complexos. Ainda na utilizacao de composicao, podemos mudar a associacao entre classes em tempo de execucao e permitir que um objeto assuma mais de um comportamento.Ao utilizar a composicao, teremos muito mais flexibilidade, alem de ser mais comum em muitos padroes de projetos. Porem, na heranca, temos uma possibilidade de desenvolver mais rapido, diminuindo o tempo de desenvolvimento, levando em conta que perdemos muito mais tempo mantendo e alterando o codigo original do que com o desenvolvimento inicial. Portanto, nosso esforco deve ser sempre voltado para