Home › DWR › Video Aula – Session DWR

Video Aula – Session DWR

Posted on Publicado em DWR 26 Comments Tagged with , , ,

Bem a série de vídeo-aulas sobre Session que a JavaMagazine está publicando chega ao fim. A última parte foi publicada no dia 6 de novembro. Para quem acompanha é a parte com exemplos “reais”.

Nesta vídeo-aula eu crio um exemplo que quase sempre utilizamos quando trabalhamos com Session no DWR, será de grande ajuda creio eu, para quem está fazendo esses tipos de funcionalidades.

A um tempinho atrás eu dei uma “tunnada” nessa funcionalidade deixando-a mais “genérica” e mais simples de se implementar. Já estou preparando um artigo e claro mais vídeo-aulas para entregar de bandeja essas facilidades ;D a vocês.

Link da vídeo-aula: link
Outras vídeo-aulas: link

PS: Lembrando que essas vídeo-aulas é exclusivo para assinantes da JavaMagazine .

26 Comments on “Video Aula – Session DWR”

  1. Muito bacana :)) Infelizmente deve-se tomar cuidados com o uso da sessão, isso derruba rapidinho a escalabilidade de uma aplicação. Depois de um tempo sua aplicação começa a “peidar” e logo logo seu tomcat morre 😛

  2. É mas dependendo como é usado não existe problema. Tem casos específicos que só podem ser resolvidos com o uso da sessão, isso nos sabemos, o problema é o uso desordenado e exagerado da sessão, ai sim, isso é prejudicial ao sistema e derruba mesmo.

    Mas em casos como inserir uma lista de itens filho em um item Pai, o uso da sessão ao meu ver é a solução mais simples, rápida, robusta e funcional, fora outros exemplos, deve-se sim tomar cuidado ao implementar algo com a sessão, mas isso serve não só para a sessão como para qualquer outra solução.

    Vlw

  3. Uso de sessão com ajax deve ser feito apenas para casualidades de segurança, como controlar o login. Itens filho deve ser usado history para isso, mas vai depender da escalabilidade que se deseja, é mais facil por na session, mas dependendo do montante de conexões, é preferivel trbalhar com history.

  4. Nao concordo Milfont. Existem casos que o uso da sessão não tem como ser evitado. Nesse caso específico do item pai com filhos, acho melhor usar mesmo com a sessão pois não vai consumir o servidor, já que vc vai carregar os dados na sessão e no final da operação ele vai enviar uma lista para salvar tudo no banco. Claro se o cara quiser que ele salve um a um diretamente no banco também pode ser feito, ai ele usária a sessão apenas para “gerenciar” essa funcionalidade. Existem casos e casos. E normalmente uma lista dessas não passa mais de 1mil registros, e mesmo que seja mais, em 90% dos casos você só precisa adicionar doi campos, ID e Nome/Descrição somente isso e isso não pesa. Porque fazer algo complicado se tem algo mais simples que serve da mesma forma ? Porque é preferível trabalhar com history, não vejo vantagens nesse caso para usar no lugar da session.

  5. Como eu disse, imagine um serviço com alto tráfego trabalhando com a session, eu passei por isso, 2 mil acessos diários já são o suficiente para se pensar em performance.
    No Diário a paginação teve que ser refeita para evitar a sessão, e olhe que eu paginava apenas as informações da grid, não era as entidades.
    Um cadastro mestre-detalhe em um serviço com m tráfego considerável tambem vai sofrer. Dessa forma se usar um framework que implemente o History corretamente como o Yui ou o Ext voce implementa fácil o controle no lado cliente e pode até salvar temporário caso a conexão caia, enfim, prefiro evitar a session e deixa-la apenas para o tratamento de informações sigilosas como controle de usuário.
    Mas isso é totalmente Off em relação ao artigo, o que importa que as informações do artigo são super importantes para quando se precisa acessar a session via DWR. Ficou muito com, dei uma olhada por cima e gostei, vou ver com mais calma agora no almoço.

  7. Já que o assunto mudou para escalabilidade e performance, você se equivocou em dizer que a utilização de sessões não compromete o servidor, pelo contrário, as sessões ficam diretamente onde o container ou servidor de aplicação se encontra, que no caso se encontra no servidor.

    Que pena que você não pode disponibilizar esses artigos aqui.

  8. Olá Carneiro, não, você que se equivocou. Não disse que a utilização da sessão não compremeteria o servidor, falei que o MAU uso dele sim. Assim como o mau uso do EJB3 ou qualquer outra solução.

    Existem funcionalidades como já repeti que não tem como não fazer usando a sessão. O seu MAU uso que com certeza vai derrubar o servidor, pegue o EJB3 e use inadequadamente para você ver como também irá derrubar o servidor.

    Carregar uma lista de 10 itens e salvar na sessão não vai prejudicar o servidor, ainda mais se você ficar limpando ao final da operação essa lista. Acho que você não entendeu o que eu e o milfont estávamos conversando. Estavamos falando de funcionalidades grandes, com concorrencia alta de acessos. Para os alguns outros casos a sessão não vai prejudicar o desempenho do servidor.

    Tenho essa mesma funcionalidade de Master-Details rodando em um sistema com mais de 5mil usuários só no ceará e foi feito um teste de stress e ela suportou tranquilamente, com concorrência de acessos e tudo.

    Observe mais uma vez que CADA CASO É UM CASO, não estou falando para se utilizar a sessão em tudo.

    Por exemplo tem gente que adora listar em uma grid todos os dados e ir percorrendo na sessão. Eu já prefiro que para cada vez que ele acesse uma paginação ele carregue aquela parte diretamente no banco, como você pode observar a suas desvantagens, é ai que entra novamente a frase: “Cada caso é um caso”, assim como você não pode afirmar que não pode usar a sessão nas funcionalidades eu também não posso afirmar que se deve utilizar para tudo.

    Sem falar que o que eu quis mostrar aqui no artigo foi como se utilizar a sessão usando o DWR e não uma funcionalidade que é a bala de prata para todos os casos de Mestre-Detalhe, e não é somente para isso, o que eu quis fazer é que com o DWR você acessa facilmente objetos na sessão, sem dificuldades, muito rápido e simples. Lembrando que isso é Ajax, Ajax acessando objetos da sessão, é isso que estou mostrando e não se a sessão derruba servidor X ou Y. ;D

    Abraços

  10. # Handerson

    Nesse caso específico do item pai com filhos, acho melhor usar mesmo com a sessão pois não vai consumir o servidor, já que vc vai carregar os dados na sessão e no final da operação ele vai enviar uma lista para salvar tudo no banco.

    Eu fiz o comentário anterior por essa frase, mas se não era isso que você estava querendo dizer, então está resolvido.

  11. Isso mesmo, só que ai vai depender, eu apenas não especifiquei o tamanho dessa carga, se for uma carga com 1 mil objetos e dependendo da concorrência ai sim, fica um pouco pesado sim para o servidor. Agora se for poucos dados não vejo problema.

    Normalmente você usa por exemplo:

    Você tem uma lista com alguns dados que o usuário cadastra em outra tela: Item A, Item B, Item C…Item Z.

    Ai na tela pai você vai adicionar esses itens em uma lista, assim como é feito ai onde você trabalha. Não vai ter essa queda de desempenho, pois a lista é pequena, é feito um único acesso para pegar essa lista, depois que você adiciona e finaliza a operação ele vai enviar essa lista para o servidor e fazer o merge com o EJB3 salvando ou excluindo os dados e logo em seguinda, deletando esse atributo da sessão. Neste caso não vejo por que não utilizar a sessão.

    Espero que tenha entendido ;D

    Abraços

  12. O problema não é a lista ser pequena ou grande, porque tanto faz uma lista com mil objetos uma unica ves como um objeto mil vezes (desconsiderando evidente as diferenças entre as operações de lista e objeto).
    Eu me referi a servidor ficar carregado em qualquer aplicação onde você não tenha controle do número de usuários, para aplicações onde voce não tem esse controle não tem como voce dizer que algo mesmo sendo pequeno não vai afetar o servidor, afeta sim.
    Por isso desconsidero o uso de session para TODAS as situações onde se usa Ajax, com exceção de controle de acesso e políticas de segurança.

  13. Sessão é prejudicial sim para uma aplicação que deseja-se escalabilidade. Mesmo quando se utiliza poucos dados na sessão prejudica a escalabilidade quando o número de usuários concorrentes no sistema cresce.

    O ideal é sempre que se utilizar sessão lembrar de limpar os dados (Algumas pessoas costumam usar filtros para isso). Problemas de sessão é um problema exponencial, não tem hardware que resolva 🙂

    Contudo, trabalhar com sessão facilita a vida de nós desenvolvedores :~

  14. hauahuahua o que eu acho engraçado é que o foco do artigo não é de modo algum discutir escabilidade ou o que for, e sim como acessar objetos na sessão usando o DWR. SÓ ISSO.

    Mas legal, viajamos um pouco. Vou fazer um post sobre isso ai discutiremos sobre isso. Se não vamos passar o dia aqui tentando provar X e Y sendo que o assunto do post é outro que não tem muito a ver.

    Abraços a todos ;D

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.