Polêmica

[quote=javaflex]
Pode ter situações úteis em aplicações de banco de dados. O SGDB é perfeitamente capaz de lidar com diversos acessos ao mesmo tempo, da mesma forma que vários usuários simultâneos. Então pode ser válido se o cenário for favorável e tiver a necessidade.

Trabalho com ASP.NET MVC e tenho situações onde o cliente precisa exportar para Excel relatórios complexos com fonte de dados variadas. Difícil alguém não passar por uma situação de relatório analítico que não demore segundos.[/quote]

Apenas estou dizendo que seu cenário não é valido na web. um cliente nunca iria esperar 10 segundos numa requisição pra receber do servidor uma string escrito “finalizado”. Isso não tem lógica nenhuma. lol

Do ponto de vista da otimização dos recursos do servidor web, é mais indicado retornar a requisição com um “processo iniciado” ao invés de “finalizado” e fazer o cliente fazer outra requisição pra saber se o processo foi finalizado.

[quote=lkbm][quote=javaflex]
Pode ter situações úteis em aplicações de banco de dados. O SGDB é perfeitamente capaz de lidar com diversos acessos ao mesmo tempo, da mesma forma que vários usuários simultâneos. Então pode ser válido se o cenário for favorável e tiver a necessidade.

Trabalho com ASP.NET MVC e tenho situações onde o cliente precisa exportar para Excel relatórios complexos com fonte de dados variadas. Difícil alguém não passar por uma situação de relatório analítico que não demore segundos.[/quote]

Apenas estou dizendo que seu cenário não é valido na web. um cliente nunca iria esperar 10 segundos numa requisição pra receber do servidor uma string escrito “finalizado”. Isso não tem lógica nenhuma. lol[/quote]
Não analise as coisas ao pé da letra. Funcional para a pessoa poder copiar e colar na Controller, podendo praticar imediatamente. O código está claro que é só para ilustrar na prática execuções em paralelo, o que você pode fazer na vida real vai ser qualquer coisa que tiver necessidade. Para fins de exemplo, uma string é a maneira mais fácil para ter algum retorno no browser. Não é esse o foco da discussão, mais uma vez você desvia o foco sem necessidade, assim como já fez nas discussões com VinyGodoy. Obviamente o retorno pode ser qualquer coisa, como um json, como um arquivo Excel a qual falei a pouco. Mesmo assim não necessariamente o retorno tem que ser algo pesado ou “palpável” se o que é feito no servidor for algo pesado, tudo depende do caso.

[quote=lkbm]Do ponto de vista da otimização dos recursos do servidor web, é mais indicado retornar a requisição com um “processo iniciado” ao invés de “finalizado” e fazer o cliente fazer outra requisição pra saber se o processo foi finalizado.
[/quote]Depende do caso que deseja atender. Não quer dizer que isso seja mais indicado que outra solução que é feita para atender outro caso. Em muitos casos o cliente faz a ação só para esperar o retorno da mesma, como você mesmo já citou em outros posts e a discussão continuou nisso. Se lá no servidor for uma situação que possa haver divisão de tarefas para processar um mesmo resultado, isso vai ajudar no tempo total da execução.

[quote=javaflex]
Não analise as coisas ao pé da letra. Funcional para a pessoa poder copiar e colar na Controller, podendo praticar imediatamente. O código está claro que é só para ilustrar na prática execuções em paralelo, o que você pode fazer na vida real vai ser qualquer coisa que tiver necessidade. Para fins de exemplo, uma string é a maneira mais fácil para ter algum retorno no browser. Não é esse o foco da discussão, mais uma vez você desvia o foco sem necessidade, assim como já fez nas discussões com VinyGodoy. Obviamente o retorno pode ser qualquer coisa, como um json, como um arquivo Excel a qual falei a pouco. Mesmo assim não necessariamente o retorno tem que ser algo pesado ou “palpável” se o que é feito no servidor for algo pesado, tudo depende do caso.[/quote]

Então tudo depende do caso e não podemos analisar cada caso? hm… ?

O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo. :smiley:

[quote=javaflex]Depende do caso que deseja atender. Não quer dizer que isso seja mais indicado que outra solução que é feita para atender outro caso. Em muitos casos o cliente faz a ação só para esperar o retorno da mesma, como você mesmo já citou em outros posts e a discussão continuou nisso. Se lá no servidor for uma situação que possa haver divisão de tarefas para processar um mesmo resultado, isso vai ajudar no tempo total da execução.
[/quote]

Nuss… ta cada vez pior.

Por favor, refira ao primeiro post do matheuslmota para entender porque métodos que causam efeitos colaterais, como inserir no banco ou executar processos, não devem retornar valor.

[quote=lkbm][quote=javaflex]
Não analise as coisas ao pé da letra. Funcional para a pessoa poder copiar e colar na Controller, podendo praticar imediatamente. O código está claro que é só para ilustrar na prática execuções em paralelo, o que você pode fazer na vida real vai ser qualquer coisa que tiver necessidade. Para fins de exemplo, uma string é a maneira mais fácil para ter algum retorno no browser. Não é esse o foco da discussão, mais uma vez você desvia o foco sem necessidade, assim como já fez nas discussões com VinyGodoy. Obviamente o retorno pode ser qualquer coisa, como um json, como um arquivo Excel a qual falei a pouco. Mesmo assim não necessariamente o retorno tem que ser algo pesado ou “palpável” se o que é feito no servidor for algo pesado, tudo depende do caso.[/quote]

Então tudo depende do caso e não podemos analisar cada caso? hm… ?

O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo. :D[/quote]
Claro que pode analisar cada caso, só não pode atropelar uma resposta indicando como melhor solução algo que não tem haver com o caso citado.

De novo querer levar o exemplo de Sleep como caso real? Os 10 segundos foram para dar tempo a pessoa notar o que acontece executando o código. Se na vida real vai ser 1, 2, 5, ou até mesmo 10 segundos, isso vai ser problema de cada situação. Parece que você fala de aplicação web como se fosse só aplicações públicas na Internet, ou nunca passou por casos envolvendo grande volume de dados ou diversas fontes de dados externas a qual você não é responsável, como por exemplo web services.

[quote=lkbm][quote=javaflex]Depende do caso que deseja atender. Não quer dizer que isso seja mais indicado que outra solução que é feita para atender outro caso. Em muitos casos o cliente faz a ação só para esperar o retorno da mesma, como você mesmo já citou em outros posts e a discussão continuou nisso. Se lá no servidor for uma situação que possa haver divisão de tarefas para processar um mesmo resultado, isso vai ajudar no tempo total da execução.
[/quote]

Nuss… ta cada vez pior.

Por favor, refira ao primeiro post do matheuslmota para entender porque métodos que causam efeitos colaterais, como inserir no banco ou executar processos, não devem retornar valor.[/quote]
O caso do matheuslmota não tem haver com o que descrevi, pois não há concorrência ou dependência em ler dados várias fontes ao mesmo tempo e retornar um documento com essas informações. Duas consultas podem rodar ao mesmo tempo, e quando ambas terminarem, ai sim a aplicação retorna o resultado.

Se você não passa por situações do tipo, não se preocupe com isso, mas também não ignore que exista a possibilidade.

[quote]De novo querer levar o exemplo de Sleep como caso real? Os 10 segundos foram para dar tempo a pessoa notar o que acontece executando o código. Se na vida real vai ser 1, 2, 5, ou até mesmo 10 segundos, isso vai ser problema de cada situação. Parece que você fala de aplicação web como se fosse só aplicações públicas na Internet, ou nunca passou por casos envolvendo grande volume de dados ou diversas fontes de dados externas a qual você não é responsável, como por exemplo web services.
[/quote]

O que são aplicações privadas na internet e porque as requisições pra elas levam 1-10 segundos ao invés de 200 ms como uma aplicação web na internet “normal”?

Parece que você queria descrever uma consulta e acabou descrevendo um comando por engano então, porque até onde pude notar ProcessoDemorado1 e ProcessoDemorado2 não realizam consulta nenhuma? :\

nunca dura 10 segundos uma requisição no seu crud de faculdade…

Pq crud “profissional” não tem problema o cliente esperar 10s na mesma requisição?

vc escreveu isso
O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo.

Você no mínimo é loko…

[quote=eduJava]vc escreveu isso
O fato é que uma requisição web nunca leva 10 segundos se você tem alguma idéia do que esta fazendo.

Você no mínimo é loko…[/quote]

…ou seu crud esta um tanto quanto lento. kkkk

Nunca leva 10 segundos PRA SER PROCESSADA PELO SERVIDOR.

É claro que pode levar mais de 10 segundos se você usar a internet discada da sua faculdade. Mas estamos falando do tempo que o servidor leva pra processar o request. Portanto não inclui o tempo que leva para o request chegar no servidor, nem o tempo que leva pro response chegar ao cliente.

Só pra deixar claro isso pra aqueles que como vc não fizeram o dever de casa.

sim meu crud tem 4 máquinas de 128 gb de memória cada uma, somente pra banco de dados oracle(fora os servidores), alguns bilhões de registros, especialista em tunning em banco de dados, e uma infinidade de coisa pra processar no servidor pra fazer todos os dias e q levam horas e horas pra fazer. Claro que posso criar uma thread e devolver para o cliente um “sucesso” e continuar processando ou fazer por algum job, mais em trocentos casos isso de criar uma thread e devolver um “sucesso” não se aplica, e os processos ficam rodando 15, 30,45,90 minutos. Nem todo sistema é igual, então sossega a piriquita aew
Minha faculdade era federal e tinha a internet mais rápida do país.

[quote=eduJava]sim meu crud tem 4 máquinas de 128 gb de memória cada uma, somente pra banco de dados oracle(fora os servidores), alguns bilhões de registros, especialista em tunning em banco de dados, e uma infinidade de coisa pra processar no servidor pra fazer todos os dias e q levam horas e horas pra fazer. Claro que posso criar uma thread e devolver para o cliente um “sucesso” e continuar processando ou fazer por algum job, mais em trocentos casos isso de criar uma thread e devolver um “sucesso” não se aplica, e os processos ficam rodando 15, 30,45,90 minutos. Nem todo sistema é igual, então sossega a piriquita aew
Minha faculdade era federal e tinha a internet mais rápida do país.[/quote]

Dizer que não faz sentido usar await no request handler de uma aplicação web é o mesmo que dizer que todo sistema é igual? hehe conte-me mais…

Pra lidar com processos demorados é mais eficiente, do ponto de vista do servidor, responder com “iniciado” (não é “sucesso”, mais um sinal que não esta fazendo seu dever de casa) imediatamente e depois ir buscar o resultado (ao invés de await). Essa é a prática recomendada pelo protocolo pra lidar com processos demorados na web. Porque você não consegue aplicar na sua aplicação é que precisa ser questionado, e não a técnica usada por toda a web “publica”. :wink: