Loading ...
Sorry, an error occurred while loading the content.

[riojug] Singletons e Thread safe Objects

Expand Messages
  • Felipe Lauksas
    Fala pessoal. Aos mais entendidos... uma pergunta que a tempos me faço. Na API do Java temos objetos que nos auxiliam na codificação, eles podem ser
    Message 1 of 3 , Jan 24, 2014
    • 0 Attachment
      Fala pessoal.
      Aos mais entendidos... uma pergunta que a tempos me faço.

      Na API do Java temos objetos que nos auxiliam na codificação, eles podem ser Thread Safe ou não citando exemplos: StringBuilder vs StringBuffer / HashMap vs HashTable e etc...

      Quando trabalhamos em um container WEB até onde sei temos concorrência de threads (Requests) que é gerenciada pelo servidor. Em um cenário que temos um Singleton  utilizado por um Servlet, por exemplo, acredito que pode haver concorrência entre Requests.

      Então a primeira pergunta: A afirmação é correta? podemos contar com concorrência ou o container  WEB resolve isso "magicamente"?

      Segunda pergunta: nesse Singleton utilizado pelo Servlet, nele contendo uma coleção que não seja Thread Safe, esta corre o risco de haver problemas com a concorrência?

      Eu nunca tive problemas utilizando non-Thread Safe Objects neste senário, mas sempre me pergunto o por que e qual é a boa prática...

      Agradeço suas opiniões!



      --
      Felipe Lauksas
      e-mail: lauksas@...
    • Romano Silva
      Felipe, o container não resolve isso magicamente. Se você tem um singleton que é concorrido por múltiplas threads, você tem que fazer ele ser thread-safe.
      Message 2 of 3 , Jan 24, 2014
      • 0 Attachment
        Felipe,

        o container não resolve isso magicamente. Se você tem um singleton que é concorrido por múltiplas threads, você tem que fazer ele ser thread-safe. Existem várias formas de se fazer isso.

        O problema é que fazendo isso, você cria um gargalo na sua aplicação. Considere bem antes de usar um singleton que precisa ser tread-safe.

        Se houver mesmo essa necessidade e o que estiver sendo acessado dentro do singleton for apenas Collections, dê uma olhada nas Concurrent lists, maps, etc. Eles permitem um acesso de leitura concorrente e escrita sincronizada.

        Grande abraço,
        Romano






        2014/1/24 Felipe Lauksas <lauksas@...>
         

        Fala pessoal.
        Aos mais entendidos... uma pergunta que a tempos me faço.

        Na API do Java temos objetos que nos auxiliam na codificação, eles podem ser Thread Safe ou não citando exemplos: StringBuilder vs StringBuffer / HashMap vs HashTable e etc...

        Quando trabalhamos em um container WEB até onde sei temos concorrência de threads (Requests) que é gerenciada pelo servidor. Em um cenário que temos um Singleton  utilizado por um Servlet, por exemplo, acredito que pode haver concorrência entre Requests.

        Então a primeira pergunta: A afirmação é correta? podemos contar com concorrência ou o container  WEB resolve isso "magicamente"?

        Segunda pergunta: nesse Singleton utilizado pelo Servlet, nele contendo uma coleção que não seja Thread Safe, esta corre o risco de haver problemas com a concorrência?

        Eu nunca tive problemas utilizando non-Thread Safe Objects neste senário, mas sempre me pergunto o por que e qual é a boa prática...

        Agradeço suas opiniões!



        --
        Felipe Lauksas
        e-mail: lauksas@...


      • Luiz Esmiralha
        Complementando a resposta anterior, caso você precise de uma estratégia de locking mais específica do que a oferecida por uma coleção concorrente ou
        Message 3 of 3 , Jan 24, 2014
        • 0 Attachment
          Complementando a resposta anterior, caso você precise de uma estratégia de locking mais específica do que a oferecida por uma coleção concorrente ou precise melhorar a concorrência de uma coleção em cenários onde a coleção é realmente grande, você pode usar a classe ReentrantReadWriteLock para travar e destravar a instância em momentos específicos.

          http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html



          Em 24 de janeiro de 2014 13:10, Romano Silva <romano.magacho@...> escreveu:


          Felipe,

          o container não resolve isso magicamente. Se você tem um singleton que é concorrido por múltiplas threads, você tem que fazer ele ser thread-safe. Existem várias formas de se fazer isso.

          O problema é que fazendo isso, você cria um gargalo na sua aplicação. Considere bem antes de usar um singleton que precisa ser tread-safe.

          Se houver mesmo essa necessidade e o que estiver sendo acessado dentro do singleton for apenas Collections, dê uma olhada nas Concurrent lists, maps, etc. Eles permitem um acesso de leitura concorrente e escrita sincronizada.

          Grande abraço,
          Romano






          2014/1/24 Felipe Lauksas <lauksas@...>
           

          Fala pessoal.
          Aos mais entendidos... uma pergunta que a tempos me faço.

          Na API do Java temos objetos que nos auxiliam na codificação, eles podem ser Thread Safe ou não citando exemplos: StringBuilder vs StringBuffer / HashMap vs HashTable e etc...

          Quando trabalhamos em um container WEB até onde sei temos concorrência de threads (Requests) que é gerenciada pelo servidor. Em um cenário que temos um Singleton  utilizado por um Servlet, por exemplo, acredito que pode haver concorrência entre Requests.

          Então a primeira pergunta: A afirmação é correta? podemos contar com concorrência ou o container  WEB resolve isso "magicamente"?

          Segunda pergunta: nesse Singleton utilizado pelo Servlet, nele contendo uma coleção que não seja Thread Safe, esta corre o risco de haver problemas com a concorrência?

          Eu nunca tive problemas utilizando non-Thread Safe Objects neste senário, mas sempre me pergunto o por que e qual é a boa prática...

          Agradeço suas opiniões!



          --
          Felipe Lauksas
          e-mail: lauksas@...





        Your message has been successfully submitted and would be delivered to recipients shortly.