Criando PreparedStatement

reutilizá-los… não crie um novo statement a todo momento, reutilize um que já esteja aberto… feche apenas no fim de toda a transação…

Interessante pergunta. Como vc chegou a conclusao que um preparedstatement esta sendo O problema de performance na sua aplicacao?

Rafael

não tem mágica…
qual SO, BD e Driver q vc ta usando?
qual java?

microfilo:

não tem mágica…
qual SO, BD e Driver q vc ta usando?
qual java?

isso pode acontecer em operaçoes… digamos em massa

numa aplicação minha, em Oracle deu o erro “número máximo de cursores abertos”… dai reutilizei os statements e funcionou.

no construtor da minha tela de vendas eu crio os prepared statement q vou usar…

eu comentei as linhas em q crio os prepared e a janela abriu bem + rapido…

aki estah o codigo dos prepared statement:

try{
        stmtIDVenda=conn.prepareStatement("SELECT * FROM SP_VENDA_ID");
        gravaVenda=conn.prepareStatement("EXECUTE PROCEDURE INCLUIR_VENDA(?,?,?,?,?,?,?,?)");
        gravaItem=conn.prepareStatement("EXECUTE PROCEDURE INCLUIR_ITEMV(?,?,?,?,?)");
        atualizaEst=conn.prepareStatement("EXECUTE PROCEDURE ATUALIZA_EST_V(?,?)"); //qtde e idprod
        gravaContaRec=conn.prepareStatement("EXECUTE PROCEDURE INCLUIR_CONTARECEBER(?,?,?,?,?,?,?)");
        }catch (Exception e){JOptionPane.showMessageDialog(null,"Erro "+e.getMessage());}

SP_VENDA_ID eh uma procedure q incrementa o generator e retorna o valor (vou precisar desse valor p/ incluir a venda e os itens)

não tem mágica…
qual SO, BD e Driver q vc ta usando?
qual java?

o SO eh windows xp, mas isso nao importa pois o sistema eh em java
BD firebird 1.5
o driver eh firebirdsqlfull.jar do Jaybird 1.5
SDK 1.4.2_06

Xeu ver se eu entendi… vc esta criando todos os statements de uma vez e deixando eles em aberto pra quando precisar, ou voce tem mesmo que chamar todas essas procedures em sequencia?

eu crio todos duma vez deixando eles em aberto p/ quando eu precisar

essas procedures sao pra registrar vendas…quando o usuario vai registrar uma venda, todas essas procedures sao chamadas, com excecao da última, q soh eh chamada no caso d vendas a prazo… :mrgreen:

tente usar a classe Callable Statement para Stored Procedures

Não deixe o objeto criado, gastando recursos à toa. Crie-os quando precisa e feche-os assim que possível.

O Lipe tah certissimo - e nao se esqueca das duas regrinhas maximas da utilizacao de recursos: “quem criou que cuide de fechar” e “fique o menor tempo possivel com as coisas abertas”

o driver JDBC do firebird ainda nao implementa transacoes com Callable Statements (e vai demora mto pra implementa isso)

gastando recursos à toa??? toda vez q o usuario inserir uma venda vou t q fica criando os PreparedStatement?? isso tornaria a inclusao mais lenta…meus prepared statement nao estao gastando recursos à toa, eu uso eles na insercao das vendas (lembrem-se q eh uma tela d registro d vendas)

antes q me perguntem por q eu to fazendo procedures p/ incluir em vez d dar um “INSERT INTO TABLE…”:
estou pensando em fazer o usuario ter permissao sobre as procedures em vez da tabela p/ aumentar a segurança do banco 8)

O problema de deixa-los abertos eh que todo PreparedStatement esta ligado a uma Connection - ou seja, voce esta sempre com uma conexao ao banco de dados aberta para cada PreparedStatement, o que nao eh lah muito saudavel, se voce tem muitos usuarios.

Se você está deixando o objeto Connection aberto … bem, simplesmente não faça isso. Se está vindo de outras linguagens de programação que mantém a danada aberta para você, cuidando para que não haja o dispêndio desnecessário de recursos, ok. Mas em Java não tem essa hehe novamente: abra recursos quando precisa deles e feche-os assim que possível. Caso contrário sua aplicação gasta toneladas de recursos sem motivo nenhum, fazendo com que fique lenta.

E quanto a stored procedures, tem certeza que vai usar FireBird para sempre? Se está usando esses procedimentos só para não escrever as consultas sql no código, há outras maneiras de fazer isso.

Aqui uma boa discussão sobre stored procedures:
http://www.guj.com.br/posts/list/8443.java

nao eh uma conexao aberta p/ cada prepared e sim uma p/ todos…vcs podem ver no meu codigo q todos os prepared sao criados pela mesma conexao…

Lipe, como assim nao deixar a conexao aberta, c os Statement, Prepared Statements, etc sao criados em cima da conexao???
nesse sistema vou usar o firebird…vc tem algo contra o firebird??? (firebird nao eh uma simples copia do interbase como muitos pensam, ele eh muito melhor q o interbase)

a aplicacao tera poucos usuarios e nao estou usando connection pool

Não tenho nada contra firebird.

Lipe, como assim nao deixar a conexao aberta, c os Statement, Prepared Statements, etc sao criados em cima da conexao????

Connection conn;
PreparedStatement ps;
ResultSet rs;
try
{
    conn = criaConexao();
    ps = conn.createStatement( consulta );
    
    rs = ps.execute();

    // faz o que precisa com o conjunto de registros
    // de preferencia passar os dados para uma collection
    // para poder fechar logo os recursos
}
catch( Exception e )
{
    e.printStackTrace();
}
finnaly
{
    try
    {
        rs.close();
        ps.close();
        conn.close();
    }
    catch( Exception ex )
    {
        ex.printStackTrace();
    }
}

Você pode encapsular esse procedimento todo num método que aceita uma query como parametro e retorna uma coleção de objetos para você.

retorna colocao d objetos???
mas eu nao estou fazendo consulta nesse frame…como eu disse anteriormente, eu to falando da minha tela d inclusao

E onde o Lipe ta fazendo consulta nesse exemplo de codigo? Se voce ignorar o resultset retornado e trocar por um executeUpdate(), pronto… quer mais de bandeija do que isso?

O pool c3p0 possui um pool de Statements tambem, dá uma verificada, acho que vai ajudar a resolver seu problema de performance. No mais concondo com o LIPE, sempre feche seus statements. E como já foi citado, utilize o CallableStatement para executar suas procedures e functions…

8. hmm…intaum o certo eh criar os statement, conexao e tal na hora d usá-los (no meu caso seria na hora d inserir…)

sobre callable statements, o driver JDBC do FB naum implementa transacoes com eles…

a proposito…há diferença em performance e tal entre criar um prepared statement com “INSERT INTO…” ou “EXECUTE PROCEDURE…”???

o q eh o c3po?? :roll:

Lich King:

a proposito…há diferença em performance e tal entre criar um prepared statement com “INSERT INTO…” ou “EXECUTE PROCEDURE…”???

o q eh o c3po?? :roll:

se for coisa simples, da na mesma "statement com “INSERT INTO…” ou “EXECUTE PROCEDURE”… se for coisa pesada, a procedure vai ser bem mais eficiente.

http://java-source.net/open-source/connection-pools/c3p0