(Estou usando BD Oracle.)
Alguém pode me ajudar?
Vc ta querendo que sua aplicação crie um usuário no DB? É isso? Desculpe a pergunta, mas caso seja isso, pq?
É isso mesmo.
Na minha aplicação eu posso inserir novos usuários para a mesma. Sendo que (a pedido do cliente - para fins de auditoria) cada usuário da aplicação deve ter um usuário no BD.
Então, no momento que eu crio um novo usuário pra minha aplicação eu preciso criar também um pro BD.
Neste link estão listados os comandos necessários para criação de um usuário no BD.
http://superuser.com/questions/268098/creating-a-new-user-in-oracle-enterprise-manager-11g
Porem, como o cliente pretende auditar isto?? fiquei curioso, pois, independentemente da criação dos usuários no BD a sua aplicação não irá acessar com apenas um usuário setado na string de conexão com o BD, ou, vc pretende logar no BD com cada usuário criado?
Eu logo no BD com o usuário logado. E isso já está implementado.
Vi o link, ele me dá os comandos para criação de novo user. Mas como posso chamar esses comando via Java?
Para esta caso eu utilizaria jdbc:
Statement st = null;
Class cls = Class.forName(<Driver JDBC>);
Connection conn = DriverManager.getConnection(<String de Conexão ao BD>,<Usuario sysdba do BD>, <Senha do usuario sysdba do BD>)
st = conn.createStatement();
StringBuilder sql = new StringBuilder();
sql.append("CREATE USER ");
sql.append(<new_user_name>);
sql.append(" IDENTIFIED BY ");
sql.append("'");
sql.append(<password>);
sql.append("'");
sql.append("DEFAULT TABLESPACE '<desired_tablespace>' TEMPORARY TABLESPACE temp");
st.executeUpdate(sql.toString());
st.close();
st = conn.createStatement();
sql.append("GRANT CONNECT, RESOURCE TO ");
sql.append(<new_user_name>);
st.executeUpdate(sql.toString());
st.close();
... e demais comandos[quote=ameliapessoa]É isso mesmo.
Na minha aplicação eu posso inserir novos usuários para a mesma. Sendo que (a pedido do cliente - para fins de auditoria) cada usuário da aplicação deve ter um usuário no BD.
Então, no momento que eu crio um novo usuário pra minha aplicação eu preciso criar também um pro BD.[/quote]
Só pense em algo, como você irá logar com o cara logado se você ainda não foi ao DB? Vc vai ter que ter no minimo duas conexões configuradas em sua app, uma para a aplicação logar seu usuário, e outra para o usuário se logar depois.
Realmente é algo bem estranho isso que seu cliente solicitou…
ameliapessoa,
me permite te alertar sobre uma coisa (pois já tive problemas com este tipo de cenário)?
Se você for usar JPA ou Hibernate nesta aplicação tome muito cuidado! Se você for usar um destes frameworks para persistência, terá que criar um EntityManagerFactory para cada usuário da aplicação, para que sua aplicação funcione como espera, e estas instâncias de EMF costumam ocupar muito espaço em memória (o espaço é proporcional ao tamanho do banco de dados).
Quando trabalhei em uma aplicação web com este cenário (um usuário no banco para cada usuário da aplicação) criávamos um EMF para o usuário no momento do login, e armazenávamos na sessão. Mesmo depois da sessão expirada os objetos (metadados) referenciados pelo EMF permaneciam na memória, e em pouco tempo levavam o servidor de aplicações a um esgotamento de memória.
Pense nisso!
[]'s
Um detalhe que esqueci de mencionar:
Este problema que citei pode ser difícil de identificar em tempo de desenvolvimento, pois costumamos testar a aplicação com apenas um usuário. Quando a aplicação vai para a produção, com vários usuários, o problema aparece.
Foi difícil identificarmos que era este o problema. Analisando a heap utilizada pela aplicação víamos que a quantidade de objetos do Hibernate aumentava gradativamente, mas demorou até percebermos que estava relacionado à criação de EMF para cada usuário.
Para se ter uma ideia, a cada login de usuário 10MB eram ocupados na memória, e estes objetos tem uma vida longa na heap. Imagine 100 usuários se logando na aplicação…
[]'s
[quote=Luiz_Gustavo]Um detalhe que esqueci de mencionar:
Este problema que citei pode ser difícil de identificar em tempo de desenvolvimento, pois costumamos testar a aplicação com apenas um usuário. Quando a aplicação vai para a produção, com vários usuários, o problema aparece.
Foi difícil identificarmos que era este o problema. Analisando a heap utilizada pela aplicação víamos que a quantidade de objetos do Hibernate aumentava gradativamente, mas demorou até percebermos que estava relacionado à criação de EMF para cada usuário.
Para se ter uma ideia, a cada login de usuário 10MB eram ocupados na memória, e estes objetos tem uma vida longa na heap. Imagine 100 usuários se logando na aplicação…
[]'s[/quote]
E como vocês resolveram?
Aí é que está jakefrog,
como só descobrimos em produção não conseguimos tirar o Hibernate, pois não daria tempo de reimplementar em JDBC puro (o que ajudaria a resolver o problema).
A medida paleativa (que está longe de ser a ideal) foi colocar a aplicação em um cluster e monitorar o uso da memória, reiniciando um dos servers quando necessário.
Na época um consultor me disse que havia um recurso no JBoss que permitia configurar a segurança declarativa integrada com o datasource, fazendo com que o datasource (sem pool) criasse conexões personalizadas para cada usuário. Eu já fiz 2 cursos de JBoss, e nunca encontrei este tal recurso, e para quem perguntei ninguém nunca ouviu falar. Sem dizer que um datasource sem um pool não serve de muita coisa.
Resumindo, foi um caminho sem volta.
Na API do JPA (1.0, que foi o que usamos) havia uma maneira de criar o EntityManager passando um Properties com algumas configurações. Eu até tentei criar um único EntityManagerFactory com um usuário padrão, e ao criar o EM tentei passar os dados de usuário, mas não adiantou nada.
[]'s
[quote=Luiz_Gustavo]Aí é que está jakefrog,
como só descobrimos em produção não conseguimos tirar o Hibernate, pois não daria tempo de reimplementar em JDBC puro (o que ajudaria a resolver o problema).
A medida paleativa (que está longe de ser a ideal) foi colocar a aplicação em um cluster e monitorar o uso da memória, reiniciando um dos servers quando necessário.
Na época um consultor me disse que havia um recurso no JBoss que permitia configurar a segurança declarativa integrada com o datasource, fazendo com que o datasource (sem pool) criasse conexões personalizadas para cada usuário. Eu já fiz 2 cursos de JBoss, e nunca encontrei este tal recurso, e para quem perguntei ninguém nunca ouviu falar. Sem dizer que um datasource sem um pool não serve de muita coisa.
Resumindo, foi um caminho sem volta.
Na API do JPA (1.0, que foi o que usamos) havia uma maneira de criar o EntityManager passando um Properties com algumas configurações. Eu até tentei criar um único EntityManagerFactory com um usuário padrão, e ao criar o EM tentei passar os dados de usuário, mas não adiantou nada.
[]'s[/quote]
Valeu. [=