Mensagens enviadas por: ranophoenix
Índice dos Fóruns » Perfil de ranophoenix » Mensagens enviadas por ranophoenix
Autor Mensagem
Acredito que a questão não é o "que" mas o "como". Você sempre pode implementar na "unha" tudo o que o EJB e/ou qualquer outra tecnologia já te entregam de bandeja para somente usar. No caso do EJB, vc pode deixar o container, por exemplo, cuidar de transações e o código da sua app ficará bem mais simples, mas, por debaixo dos panos, o container estará fazendo o trabalho que vc poderia (e em alguns casos vai querer) fazer na "unha".

Então, IMHO, não existe nada que só pode ser feito com EJB. Tudo vai depender em que nível de abstração vc vai querer trabalhar a solução que estará desenvolvendo.
Danilo,

A solução rápida é vc alterar/colocar a seguinte configuração no seu postgresql.conf:

bytea_output = 'escape'


O default na versão 9 é hex.

Se vc fez um dump da versão antiga, atualizou o postgres, restaurou o dump e atualizou o seu driver jdbc, acredito que vc não precisa fazer essa alteração acima. O driver deve tratar essa questão de forma transparente.
Perfomance é sempre uma variável que temos que ter muito cuidado na hora de mensurar. Em cenários OLTP uma tabela de 11 milhões de registros pode ser o menor de seus problemas.

Algumas perguntas importantes:

Quantos usuários simultâneos minha aplicação vai suportar?
Quantas transações por segundo/minuto minha base deve ser capaz de processar?
Qual o crescimento estimado de minha base? O banco suporta particionamento de tabela (o Caché "implementa" esse recurso através de um técnica que ele chama de mapeamento de subscrito, mas não tem ferramentas para abstrair a exportação/importação dos dados particionados para outros ambientes - desenvolvimento, homologação -, por exemplo).
E por aí vai...

A fama do Caché ter alta perfomance vem da época de aplicações cliente-servidor/terminal/mainframe (antigo Mumps) e acesso direto via global (acesso hierárquico), ou seja, caso o critério de busca coincidisse com a chave da árvore o resultado era quase que imediato, caso contrário, o desempenho era extramento ruim, tendo que criar artifícios como globais de ponteiro (estruturas hierárquicas que funcionavam como índices para as globais de dados) para otimizar o acesso.

Caso vc acesse somente a visão relacional ou OO esse ganho não existe e vc deve tomar cuidado redobrado com a consistência dos seus dados (READ UNCOMMITED).

É isso aí, espero ter ajudado.

Abração.
Aconselho você estudar bem o Caché antes de colocá-lo em produção, pois ele pode afetar consideravelmente a forma como sua aplicação vai ser escrita com relação a consistência dos dados e até mesmo perfomance. Alguns pontos:

- Ele utiliza, por padrão, nível de isolamento READ UNCOMMITED;

- Você pode setar READ COMMITED, mas funções agregadas continuarão se comportando como READ UNCOMMITED;

- Muitos problemas de LOCK em situação de concorrência (agravado se setado READ COMMITED na conexão). Ele "trava" o registro mesmo durante o select (não há o comando select ... for update) (existe um cláusula %NOLOCK, mas, por razões óbvias, deve ser utilizado com muita cautela);

- Não importa o que te digam, o Caché é um banco hierárquico, no fim tudo acaba em globais. O que ele cria são "visões" relacionais e OO para esses dados hierárquicos.

- Enfim... o Caché tem muitas, mas muitas particularidades que devem ser bem conhecidas antes de se desenvolver uma aplicação robusta sobre ele.

Quanto a perfomance, aconselho vc a usar este software http://sourceforge.net/projects/benchmarksql/ e comparar com outros SGBDs em condições de hardware/plataforma equivalentes.

Tenho experiênciência de aproximadamente 7 anos na administração de bases de dados Caché.
vitu wrote:
Veio que porra é essa? Esqueceu das mulheres heheheeh.

uhauhahuuha dei mole.

As certificações Beta eram gratuitas antigamente. Eu não dúvido nada desses valores.


Muito bem lembrado.

One way around the cost is to write the beta exams while Oracle tweaks the final product. You can currently write the Java SE 7 Programmer I test while it is in beta for only $50, although the opportunity expires on December 17th, so you better book now. The Java SE 7 Programmer II test has not gone to beta yet, but that will likely be announced within the next couple of months, giving early worms a chance to pass both exams for the low, low price of only $100.

Of course, if you miss out on the beta, you better start saving. A $300 Java Professional certification will soon become a thing of the past.


Pelo que entendi da notícia, o autor fala de uma mudança que está para ocorrer e não que já ocorreu. Vamos ver o que ocorrerá depois do dia 17 de dezembro.

Acredito que o número de acesso do "The Server Side" é consideravelmente alto, entretanto os comentários relacionados a esta notícia ainda são bastante modestos. No mínimo, nos leva a duas conclusões básicas:

1) O pessoal acha que é uma notícia que nem vale à pena ser comentada em virtude do seu possível sensacionalismo;

2) O pessoal está aguardando as cenas do próximo capítulo antes de ter alguma opinião formada.


Grandes mudanças foram feitas pela Oracle com relação ao esquema de certificação para o Java 7.

Talvez a mais perceptível, além da mudança do nome que agora passa a ser OCP, seja o valor: passou de $300,00 para $600,00. Mas não ache que as mudanças param por aí:


So what?s changing? Well, at the most fundamental level, the JDK version being tested has been updated. The latest incarnation of the Java Professional designation from Oracle will be testing candidates on version 1.7 of the JDK, not Java 5 or Java 6, as the previous examinations did.

Secondly, the name of the designation is changing. There is no longer a Sun Certified Java Professional (SCJP) designation. Instead, the new vernacular is OCP, standing for Oracle Certified Professional. Of course, Oracle started with this re-branding of the designation once the Sun takeover was completed. However, the old SCJP name has managed to stick around, largely owing to the fact that the actual exam never really changed, either in content or format. This time though, the change is significant, so you can kiss the old SCJP name goodbye.

Thirdly, you can no longer simply walk into a Prometric testing center (Pearson VUE is the new exam proctor), correctly answer the majority of the sixty or so question, multiple-choice exam, and walk out with your Java Professional designation. Obtaining the Professional designation is now a two step process, which starts first with passing the Oracle Certified Associate exam, or as it?s referred to on Oracle?s certification site, the Java SE 7 Programmer I test. Once you pass the new Associate exam, you are then qualified to write the Java SE 7 Programmer II exam, and if you pass that, you?ll have gained your Java Professional designation.


Notícia completa: http://www.theserverside.com/news/thread.tss?thread_id=63369
O pessoal tem resolvido utilizando esse artifício:

http://forum.primefaces.org/viewtopic.php?f=3&t=13151#p43963
Acho que esse problema tem uma relação com esse bug:

http://java.net/jira/browse/JAVASERVERFACES-2215


Temos uma biblioteca de componentes que começou a dar esse erro quando atualizamos para o Glassfish 3.1.1, no 3.0 funcionava normalmente. Acessando qualquer página "menor" (tamanho em bytes), a sessão é criada e podemos acessar páginas "maiores" sem problemas. O fogo é que qualquer workaround para isso parece POG.
Mais uma notícia para movimentar a comunidade Java.


As previously communicated our strategy is to converge the HotSpot and JRockit JVMs into a single best-of-breed JVM (blog, press release). While most of the work involved in this effort is engineering - taking ideas and features from JRockit and porting them over to OpenJDK - we have also been working on convergence from a licensing perspective. This work is now complete, and we have changed the license that we distribute both the Oracle (Sun) JDK and JRockit under. The new license is a slightly modified version of the Binary Code License that Sun has used for various Java downloads for many years. The full text of the new license is available here. For comparison, the old BCL is available here.


Link da notícia completa: http://blogs.oracle.com/henrik/entry/jrockit_is_now_free_and
O sucesso do PrimeFaces está diretamente ligado ao sucesso do JSF 2. É a vantagem de sair na frente.

As outras libs demoraram demais para lançarem versões estáveis.
chun wrote:Na real , alguem aqui está usando seriamente esta linguagem ?



Nas minhas atividades de Sysadmin aqui no Tribunal, todos os meus scripts são desenvolvidos em groovy e não tenho o que reclamar, muito pelo contrário. É muito bom poder abrir conexões jdbc, utilizar as APIs do mundo Java, as facilidade adicionadas pelo GDK, integração com shell script, AntBuilder, etc. Não posso te dizer se usamos seriamente essa linguagem, mas utilizamos a linguagem para monitorar, processar e executar coisas muito sérias. Obviamente, poderíamos utilizar outras linguagens para este fim, mas outro ponto forte do groovy é que, além de rodar sobre a JVM, vc aproveita todo o know-how adquirido com a API Java padrão, somado as facilidades citadas anteriomente.

Ah! E tem vários projetos de cunho científico que estão obtendo excelentes resultados com o Groovy++, inclusive obtendo perfomance superior a linguagens como Scala, por exemplo. Tem uma thread rolando na lista de usuários Groovy com o título "Groovy++ performance", podem dar uma conferida.

Abs,

Robert

Acaba de sair do forno:


The Groovy development team is really pleased and proud to announce the release of the final version of Groovy 1.8.0!

After a lot of work and efforts throughout four betas and four release candidates, version 1.8 of Groovy has been long in the making, but is packed with tons of new features and enhancements, for your productivity, and your pleasure. In particular, you'll be happy to learn about:

  • the new Domain-Specific Language authoring capabilities for more readability and expressivity of your business rules,

  • the runtime performance improvements,

  • the bundling of the GPars parallel and concurrency library,

  • the built-in JSON support,

  • the new compile-time meta-programming features (several new useful AST transformations),

  • the new functional programming aspects of closures,

  • and much more.


  • To get all the details, with code samples, we have prepared an in-depth release notes document. Please have a look at it to learn more about the features listed above, and discover other smaller enhancements as well.

    You can download Groovy 1.8 in our download section and you can have a look at the list of JIRA tickets that have found their way into this major release.

    We'd like to thank all those who participated and contributed to this release: users, contributors, committers, framework writers, IDE developers, book authors. Without you all, Groovy wouldn't be the great productive language it is now. And again, without you all, Groovy wouldn't be surrounded by its vibrant, active and rich ecosystem, giving you advanced tools and frameworks for building web applications (Grails, Gaelyk) or rich desktop applications (Griffon), for building your own projects (Gradle), for testing your projects (Spock, Geb), for tackling the concurrency and parallel problems on our multi-core / multi-processor architectures (GPars), or for improving the quality of your Groovy code bases (CodeNarc for static code analysis, GContracts for design by contract).

    Enjoy this release!



    Download: http://groovy.codehaus.org/Download
    Concordo em gênero, número e grau com o Marcos. E, por incrível que pareça, com o JEE 6 a adoção do Seam é até questionável. Perguntas que chovem nas listas do seam hoje são sempre assim: "Seam or JEE 6 only?". Boa parte das idéias do Seam 2 foram incorporadas ao JEE 6. O Seam 3 só constrói alguns módulos "periféricos" totalmente opcionais, por isso que não acredito que ele vai ter o mesmo boom que teve no JEE 5. Boa parte dos problemas do JSF 1.x era devido a integração com JSP, por isso que a criação de componentes era relativamente trabalhosa (não digo difícil). O JSF 2 utiliza facelets e fazer componentes ficou trivial, qualquer desenvolvedor que trabalhe com xhtml faz um rapidinho. Praticamente, grosseiramente falando, está bem semelhante a desenvolver taglibs no JSP.

    Aconselho para quem quiser aprender mais sobre o JSF 2, sem preconceitos, fazer a leitura desse material:

    Core JavaServer Faces (3rd Edition)


    Abs,
    asaudate wrote:
    ranophoenix wrote:Um artigo que acho bastante relevante nessas discussões sobre perfomance, benchmarks, desempenho, etc:


    http://engineroom.mixx.com/2008/08/10/ruby-on-rails-vs-java-vs-c-vs-assembler/


    Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.

    Abs,


    Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).

    Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?



    Realmente, mas acho que em relação ao compra fácil pouco tem haver com o fato de ser JSF. Com o Firebug percebe-se que os maiores "vilões" são os SWFs (Flash).
     
    Índice dos Fóruns » Perfil de ranophoenix » Mensagens enviadas por ranophoenix
    Ir para:   
    Powered by JForum 2.1.8 © JForum Team