ago 01

Estados de um objeto gerenciado por um EntityManager

Neste post falarei um pouco de como a especificação JPA 2 trata as entidades manipuladas pelos EntityManagers. As principais funções dos EntityManagers são:

  1. Como o próprio nome já diz, gerenciar as entidades;
  2. Sincronizar o estado dos objetos com os dados correspondentes no banco de dados

Ao falarmos em gerenciar uma entidade nos referimos a como um EntityManager manipula uma entidade, e para isso é necessário entender os estados possíveis que uma instância pode assumir para um EntityManager. São 4 estados possíveis:

  • Transient

Neste estado seu objeto acabou de ser criado e o atributo que foi anotado com @Id não possui valor . Toda vez que você dá um new em um objeto de uma Entidade este é o estado que ele se encontrará.

  • Managed

Neste estado o objeto possui valor no atributo anotado com @Id, sendo este valor atribuido pelo EntityManager e não setado manualmente. Toda vez que ocorrer uma sincronização através de um flush ou um commit, os dados do objeto são atualizados no os dados do banco de dados.

  • Removed

Neste estado,assim como no estado managed, o objeto possui valor no atributo anotado com @Id, sendo este valor atribuido pelo EntityManager e não setado manualmente. Porém quando ocorrer uma sincronização através de um flush ou um commit, o objeto passa a não ter mais vínculo com o banco de dados.

  • Detached

Neste estado,assim como no estado managed, o objeto possui valor no atributo anotado com @Id, sendo este valor atribuido pelo EntityManager ou setado manualmente. Porém este objeto não possui mais vínculo com o EntityManager, logo ele não será mais sincronizado com o banco de dados, e qualquer alteração realizada com ele residirá somente na memória da aplicação e não no banco de dados.

Para trocar de estados o EntityManager nos fornece os seguinte métodos:

  • persist : Transient -> Managed
  • merge : Transient -> Managed / Detached -> Managed
  • evict, clear ou close : Managed -> Detached
  • remove : Managed -> Removed

 

Tendo esses estados em mente e também como transitar entre eles, você consegue ter um controle muito melhor sobre o que você está fazendo ao utilizar JPA.

Fica a dica!

 

 

jul 17

Adicionando um Datasource Postgresql ao Jboss 7.1

Pra quem usa ou usava jboss 6, era bem simples você adicionar um datasource novo, bastava você copiar o default e modificar as configurações, gravando esse novo arquivo na pasta deploy do seu server. Porém no Jboss 7 é um pouco diferente, e, diria eu, um tanto quanto burocrático.

Primeiramente é necessário baixar os drivers necessários de acordo com seu banco.

Em seguida copie para

jboss-as-7.1.1.Final/modules/org/postresql/main/

O jar baixado.

O jar precisa necessariamente estar embaixo da pasta main. Além disso nesta pasta main também tem que estar um arquivo xml : module.xml com o seguinte conteúdo:

 
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
    <properties>
        <property name="jboss.api" value="private"/>
    </properties>

    <resources>
        <resource-root path="postgresql-X.X-XXX.jdbcN.jar"/>
    </resources>

    <dependencies>
        <module name="javax.api"/>
    </dependencies>
</module>

Agora abra o arquivo jboss-as-7.1.1.Final/standalone/configuration/standalone.xml  e procure pela tag <subsystem xmlns=”urn:jboss:domain:datasources:1.0″>  . Dentro dela deverá ser adicionado o seguinte conteúdo:

<datasources>
    <datasource jta="false" jndi-name="java:/PostgresDS"
        pool-name="postgres-ds" enabled="true" use-ccm="false">
        <connection-url>jdbc:postgresql://localhost:5432/meu_banco
        </connection-url>
        <driver-class>org.postgresql.Driver</driver-class>
        <driver>postgresql</driver>
        <security>
            <user-name>usuario</user-name>
            <password>senha</password>
        </security>
        <validation>
            <validate-on-match>false</validate-on-match>
            <background-validation>false</background-validation>
        </validation>
        <statement>
            <share-prepared-statements>false</share-prepared-statements>
        </statement>
    </datasource>
    <drivers>
        <driver name="postgresql" module="org.postgresql" />
    </drivers>
</datasources>

Agora… Nada mais a ser feito, fora restartar o jboss, ufa né, bem chatinho criar um datasource a partir da versão 7 do jboss, mas é isso aí.

 

 

out 01

Achar objetos bloqueados ORACLE

Estava eu aqui no trabalho precisando rodar uma procedure de updates e nada da procedure terminar. Fui verificar em v$session e lá mostrava que minha sessão estava bloqueada em uma determinada linha. Porém não havia nenhuma outra sessão concorrente em atividade. Então ao rodar o script abaixo consegui descobrir todos os objetos que estão bloqueados no meu banco. Para executar tal sql é necessário estar de system, ou algum usuário com permissão de dba.

SQL:
select substr(to_char(c.LOCKWAIT),1,8) lockwait
,substr(to_char(b.session_id)||’,’||to_char(c.serial#),1,12) sid_serial#
,c.status
,rpad(c.osuser,8) unix
,rpad(c.username,8) ora
,to_char(c.logon_time,’dd/mm hh24:mi:ss’) logon_time
,a.object_name Tabela
,decode(b.locked_mode,1,’No Lock’,
2,’Row Share’,
3,’Row Exclusive’,
4,’Share’,
5,’Share Row Excl’,
6,’Exclusive’,null) Status_Lock
,rpad(c.module,15) Prog
,c.terminal terminal
,rpad(c.action,20) acao
from all_objects a
, v$locked_object b
, v$session c
where
b.object_id = a.object_id
and b.session_id = c.sid
order by 6, 7 desc

out 01

Utilizando information_schema postgres

Para aqueles que utilizam o postgres em suas aplicações de pequeno porte, pode não ser muito útil minha dica, porém para aplicações que utilizem centenas de tabelas a alteração em massa dos dados de definição do banco são de fundamental importância na eficiência de um projeto. Vou dar uns exemplos que utilizo no estágio que são de grande valia.

Digamos que você tem nas suas mão um schema com mais de 100 tabelas  sendo que essas tabelas foram criadas todas com letras maiúsculas , o que leva o postgres a aceitar somente as  consultas utilizando aspas ( ” )  envolvendo o nome das tabelas e dos atributos um pé no saco isso . O que fazer então para fazer as consultas só jogando o nome das tabelas? A idéia principal então é alterar o nome das tabelas para letras minúsculas, e também seus campos. Porém são mais de 100 tabelas , o que caso você vá fazer isso através do PGadmin vá levar algumas horas desnecessárias . Então o que fazer? É aí que vem o information_schema para salvar a vida dos dbas de plantão. Para tal façanha faremos um select na tabela information_schema.tables só que da seguinte maneira:

SELECT  ‘ALTER TABLE  nome_do_schema.”‘ || table_name ||'” RENAME TO ‘||LOWER(table_name) ||’;’
FROM information_schema.tables
WHERE table_schema = ‘nome_do_esquema’

Através deste Select vc terá o comando de alteração para todas as tabelas do schema assim só tendo que copiar e colar o resultado para uma nova guia de query do postgres e eliminar as aspas( ” ) que o postgres coloca no início e no final de cada comando( Opa ! perae kct!! Trabalho de corno não!!)  . Bom voltemos um pouquinho então , utilizaremos um programinha editor de texto qualquer, no meu caso eu uso o editplus , onde colo o resultado da query e mando subsituir “ALTER po ALTER e “; por  ; assim poupando-nos do trabalho de corno. Após feito isso colo os comandos  sem as malditas aspas no início e no final de cada linha na tela de Query do pgAdmin e mando executar os comandos. Voi-lá, agora é só esperar o postgres fazer o resto, poupando-lhe um tempo valioso.

Tenho muito mais dicas de como usar o information_schema para facilitar modificações em massa. Mas cada um utilize para o que for preciso, apenas estou aqui para dar o pontapé inicial.