Oracle desiste do projeto Kenai

evandro.santos wrote:

Felagund wrote:

evandro.santos wrote:

jEder wrote:Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

No dia que vc brinca com o Postgre vc vai ver q o oracle não é tão bom assim não, e firebird? Firebird é horrivel.

Desculpe, escrevi errado, Já trabalhei com Postgres, Oracle e Firebird.

Em minha experiência com o Postgres utilizava um banco bastante grande e o processo de Vacuum era sofrível, com a evolução do banco, foi adicionado a funcionalidade de particionamento, dessa forma passei a excluir a partição (não precisava de VACUUM), porem particionamento consumia muito processado.
Outro problema era adicionar JOBs, como o recurso era novo, as vezes tinha alguns problemas.

Hoje ainda utilizo Postgres em meus projetos pessoais, mas nenhum deles chega ao pico de 100 transações em um segundo. Não arriscaria colocar o postgres em uma situação como essa....

Utilizamos bastante o postgre em sistemas concorrentes com varias transações simultaneas, e em alguns casos ele se sai melhor que o oracle, temos 2 sistemas com a mesma arquitetura, porém um roda usando Oracle e o outro Postgre, e te garanto que a performance do que roda postgre é superior, pode ser o uso do JPA, quem sabe em transações gerenciadas usando JDBC o oracle seja mais rapido, mas no caso do JPA o Postgre da um baile

Forum Spammer Membro desde: 20/02/2008 12:32:59 Mensagens: 1802 Offline

Felagund wrote:
... pode ser o uso do JPA, quem sabe em transações gerenciadas usando JDBC o oracle seja mais rapido, mas no caso do JPA o Postgre da um baile

Isso porque quando você faz uma consulta por JPA o framework gera um comando SQL e executa do banco de dados. Se esse SQL for construído da maneira mais eficiente que o banco reconhece, beleza. Se não for, vai perder performance.

O Oracle permite algumas construções "sinistras" que permite gerar consultas enxutas e de alta performance, talvez a implementação NO SEU CASO não conseguiu extrair isso.

Claro, que hoje é praticamente consenso que é preferível ocasionalmente perder um pouco de performance na aplicação mas mante-la independente de banco, mas isso é outra discussão "acalourada".

No nosso caso, tínhamos um banco postgres no nosso Call Center (uns 600 atendentes) e o número de consultas era muit o grande, muitas delas complexas e pesadas. Chegou a um ponto de que tínhamos de escolher se faríamos um upgrade do hardware do servidor ou passaríamos para Oracle ou Sybase. Fazendo testes, vimos que o upgrade de banco sairia bem mais barato.

Forum Spammer Membro desde: 20/02/2008 12:32:59 Mensagens: 1802 Offline

Ah, não usávamos JPA na época. Talvez se estivesse usando, o Posgres aguentaria, já que muita carga iria para o servidor de aplicação

Felagund wrote:

evandro.santos wrote:

Felagund wrote:

evandro.santos wrote:

jEder wrote:Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

No dia que vc brinca com o Postgre vc vai ver q o oracle não é tão bom assim não, e firebird? Firebird é horrivel.

Desculpe, escrevi errado, Já trabalhei com Postgres, Oracle e Firebird.

Em minha experiência com o Postgres utilizava um banco bastante grande e o processo de Vacuum era sofrível, com a evolução do banco, foi adicionado a funcionalidade de particionamento, dessa forma passei a excluir a partição (não precisava de VACUUM), porem particionamento consumia muito processado.
Outro problema era adicionar JOBs, como o recurso era novo, as vezes tinha alguns problemas.

Hoje ainda utilizo Postgres em meus projetos pessoais, mas nenhum deles chega ao pico de 100 transações em um segundo. Não arriscaria colocar o postgres em uma situação como essa....

Utilizamos bastante o postgre em sistemas concorrentes com varias transações simultaneas, e em alguns casos ele se sai melhor que o oracle, temos 2 sistemas com a mesma arquitetura, porém um roda usando Oracle e o outro Postgre, e te garanto que a performance do que roda postgre é superior, pode ser o uso do JPA, quem sabe em transações gerenciadas usando JDBC o oracle seja mais rapido, mas no caso do JPA o Postgre da um baile

Concordo com você com relação a esse tipo de performance, o Oracle tem algumas particularidades estranhas. Se você faz uma consulta, onde um dos paramentos é a data, e você utiliza o default (passar um objeto Timestamp) o Oracle tem uma performance horrível, nesse caso ele tem que usar o terrível to_date('formato', 'data em string'), resumindo a performance atrapalha na portabilidade.

Espero que o toplink tenha otimizações para o Oracle...

This message was edited 1 time. Last update was at 03/02/2010 12:07:19

Vou odiar a Oracle pro resto da vida agora que vão cancelar o kenai, tinha vários projetos lá...

vou ter que transferir tudo pro google code agora... que trabalheira que essa oracle dá...

acho que vou até fazer uma cópia do código-fonte do netbeans, pena que não temos o do kenai...

HelloWorld Membro desde: 18/03/2009 12:16:00 Mensagens: 18 Offline

Se você fosse um pouco mais educado e não viesse querendo fazer confusão eu responderia sem problemas. Mas já que é assim... procure no google.

Em que parte eu não fui educado? Pedi que por favor, você citasse exemplos já que a sua própria afirmação dizia serem muitos. E você não quis responder ou não foi capaz, e tentou confundir, dizendo que eu estava fazendo confusão. Pra cima de mim com essa não.

marcos.junqueira wrote:Vou odiar a Oracle pro resto da vida agora que vão cancelar o kenai, tinha vários projetos lá...

vou ter que transferir tudo pro google code agora... que trabalheira que essa oracle dá...

acho que vou até fazer uma cópia do código-fonte do netbeans, pena que não temos o do kenai...

Eu bem que queria o kenai pra instalar na intranet daqui da empresa. A gente na verdade quer é um forge com as ferramentas de comunicação que o netbeans tinha com o kenai.

This message was edited 1 time. Last update was at 03/02/2010 18:17:47

Eu não usava o Kenai, mas qual era a funcionalidade dele? Apenas de repositório e colaboração ou também poderia executar os códigos semelhante ao GAE?

Ps: A conversa anda bem quente no post sobre o fim do Kenai: http://blogs.sun.com/projectkenai/entry/the_future_of_kenai_com

É um bom projeto, só acho que não estavam dando a devida atenção.

Thread.start() Membro desde: 11/01/2008 19:43:12 Mensagens: 36 Offline

Pessoal,

Como eu já havia comentado, não vão desistir do Kenai. Vejam a notícia completa:
http://blogs.sun.com/projectkenai/entry/the_future_of_kenai_com

". We don't believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community. We are in the process of migrating java.net to the kenai technology."

[]s
Yara
http://twitter.com/yarasenger
http://blog.globalcode.com.br
http://www.eletronlivre.com.br

Então é o kenai.com que está saindo de cena, e não o projeto.

This message was edited 1 time. Last update was at 07/02/2010 23:28:19

A Oracle já começou a "matar" os projetos da Sun...
(mesmo que seja só o kenai.com)
Esse não é um bom começo...

Forum Spammer Membro desde: 20/02/2008 12:32:59 Mensagens: 1802 Offline

HelderC wrote:A Oracle já começou a "matar" os projetos da Sun...
(mesmo que seja só o kenai.com)
Esse não é um bom começo...

Por que não? Se eles querem tornar a divisão lucrativa, eles precisam cortar o que dá prejuízo ou que é redundante. Isso inclui projetos E pessoas.

Boas notícias,

Gentlepeople,

In an effort to get information out to the Kenai community quickly, while trying to manage the integration of our two companies, I think we did a poor job at communicating our plans for Kenai.com to you. I would like to remedy that now. Our strategy is simple. We don't believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community. We are in the process of migrating java.net to the kenai technology. This means that any project currently hosted on kenai.com will be able to continue as you are on java.net. We are still working out the technical details, but the goal is to make this migration as seamless as possible for the current kenai.com projects. So in the meantime I suggest that you stay put on kenai.com and let us work through the details and get back to you later this month.

Thanks for your feedback and patience.

Ted Farrell
Oracle Corporation

Recebi esse e-mail da Oracle.

Desisti de tirar meu projeto de lá após essa explicação.

JavaEvangelist Membro desde: 21/07/2005 08:51:27 Mensagens: 444 Offline

Desde que o javanet tenha mercurial, pra mim tah otimo, pq voltar pra svn vai ser complicado.

Notícias, artigos e o maior fórum brasileiro sobre Java