JobMonitor - Histórico de revisão

Rodrigogml: /* Session Context do Job */

2022-02-12T15:20:46Z

Session Context do Job

← Edição anterior		Edição das 15h20min de 12 de fevereiro de 2022
Linha 41:		Linha 41:
	Siga o exemplo que foi utilizado para o método de geração do SPED:		Siga o exemplo que foi utilizado para o método de geração do SPED:
	{{java\|Exemplo Tarefa em Execução em Background\|<syntaxhighlight lang="java">		{{java\|Exemplo Tarefa em Execução em Background\|<syntaxhighlight lang="java">
	@Override		@Override
	@Security(action = SecurityAction.HASKEY, key = BISSystem.SECKEY_COMPANY_FISCAL_SPED_GENERATE)		@Security(action = SecurityAction.HASKEY, key = BISSystem.SECKEY_COMPANY_FISCAL_SPED_GENERATE)
	public JobStatus generateSPED(String uuid, SPEDOptionBeanVO optBean) throws BISException {		public JobStatus generateSPED(String uuid, SPEDOptionBeanVO optBean) throws BISException {
	Job job = new Job("Generate SPED") {		Job job = new Job("Generate SPED") {
	@Override		@Override
	public Object runJob(Job job, JobStatus jStatus) throws Throwable {		public Object runJob(Job job, JobStatus jStatus) throws Throwable {
	return KernelCrud.getBISFacadePrivate().generateSPEDBackground(uuid, optBean, jStatus.getJobUUID());		return KernelCrud.getBISFacadePrivate().generateSPEDBackground(uuid, optBean, jStatus.getJobUUID());
	}		}
	};		};
	job.start();		job.start();
	return job.getJobStatus();		return job.getJobStatus();
	}		}
	</syntaxhighlight>}}		</syntaxhighlight>}}

Rodrigogml: /* Criando o Job */

2022-02-12T15:20:17Z

Criando o Job

@@ Linha 40: / Linha 40: @@
 Siga o exemplo que foi utilizado para o método de geração do SPED:
+{{java|Exemplo Tarefa em Execução em Background|<syntaxhighlight lang="java">
 === Padrão de Nomenclatura ===

Rodrigogml: /* Session Context do Job */

2022-02-12T15:19:05Z

Session Context do Job

← Edição anterior		Edição das 15h19min de 12 de fevereiro de 2022
Linha 33:		Linha 33:
	== Session Context do Job ==		== Session Context do Job ==

	~~Note~~ que depois que o Job é disparado, a Thread principal do usuário é finalizada retornando o JobStatus para o usuário. Uma vez que a chamada é retornada o contexto de sessão do EJB é finalizado~~. Assim a thread do~~ Job não conseguirá mais acessar o banco de dados ou outros recursos que dependam do contexto.		Quando o job é utilizado para executar uma tarefa no CRUD, é preciso se atentar que depois que o Job é disparado, a Thread principal do usuário é finalizada retornando o JobStatus para o usuário. Uma vez que a chamada é retornada, o contexto de sessão do EJB é finalizado, e o Job não conseguirá mais acessar o banco de dados ou outros recursos que dependam do contexto.

	Para resolver isso ~~há duas maneiras possíveis dependendo do trabalho a ser executado:~~		Para resolver isso é preciso que o Job faça a chamada através da fachada para que um novo contexto seja criado para ele.
	* '''Poucos ou quase nenhum acesso de consulta ao banco de dados''' - Caso a lógica do Job ~~não necessite muitos acessos~~ a ~~lógica pode ser colocada diretamente dentro da Thread e cada acesso que for abre uma nova~~ chamada através ~~dos métodos já existentes na Fachada. Tenha em mente que cada acesso tem o custo de chamada de~~ fachada e criação do contexto. Além disso, a lógica não ficará completamente dentro do mesmo contexto, assim cada rollback só é executado por chamadas, em caso de falha não terá um rollback completo do job.
	* '''Lógica mais completa com múltiplos acessos e contexto de rollback "único"''' - Em caso de lógica mais complexa que ~~faça alterações em partes ou realize muitos acessos é recomendado criar~~ um ~~outro método auxiliar e chamado através de uma fachada para que o~~ contexto seja criado ~~desde o princípio e controlado de forma sólida. Para esses métodos, que não devem ser publicados na fachada, utilize a fachada privada '''BISFacadePrivate'''~~.

	~~=== Padrão de Nomenclarura ===~~		Nestes casos a recomendação é que dentro da própria fachada ('''BISFacade''') seja criado o Job que chama o método correspondente da fachada privada ('''BISFacadePrivate'''). Para uma chamada simples não vale a pena tumultuar os arquivos do CRUD com um método só para isso.

	~~Quando for necessário criar um método auxiliar~~ para ~~executar a tarefa do Job através da chamada da fachada privada. Utilize~~ o ~~mesmo nome~~ do ~~método~~ que ~~cria~~ o ~~job acrescido do~~ sufixo "Background". ~~Mesmo que~~ a ~~assinatura~~ do método ~~seja diferente (parâmetros~~ e ~~retornos diferentes)~~. ~~Assim fica fácil a identificação de ambos os métodos~~ e ~~evita confusões~~.		Siga o exemplo que foi utilizado para o método de geração do SPED:


			=== Padrão de Nomenclatura ===

			Os métodos que trabalham em background (orientados por um Job), devem ter o sufixo "Background" no nome. Facilitando assim a pesquisa e entendimento sobre as funções do método. Além de receberem o jobUUID como parâmetro.


			{{stop\|Não Passar o JobMonitor pela Fachada\|Ao passar o JobMonitor pela fachada o objeto é clonado e a referência perdida. Por isso passe sempre o jobUUID e recupere o JobStatus dentro do método.}}

	== Interrompendo o Job ==		== Interrompendo o Job ==

Rodrigogml: /* Session Context do Job */

2022-02-12T15:07:20Z

Session Context do Job

← Edição anterior		Edição das 15h07min de 12 de fevereiro de 2022
Linha 38:		Linha 38:
	* '''Poucos ou quase nenhum acesso de consulta ao banco de dados''' - Caso a lógica do Job não necessite muitos acessos a lógica pode ser colocada diretamente dentro da Thread e cada acesso que for abre uma nova chamada através dos métodos já existentes na Fachada. Tenha em mente que cada acesso tem o custo de chamada de fachada e criação do contexto. Além disso, a lógica não ficará completamente dentro do mesmo contexto, assim cada rollback só é executado por chamadas, em caso de falha não terá um rollback completo do job.		* '''Poucos ou quase nenhum acesso de consulta ao banco de dados''' - Caso a lógica do Job não necessite muitos acessos a lógica pode ser colocada diretamente dentro da Thread e cada acesso que for abre uma nova chamada através dos métodos já existentes na Fachada. Tenha em mente que cada acesso tem o custo de chamada de fachada e criação do contexto. Além disso, a lógica não ficará completamente dentro do mesmo contexto, assim cada rollback só é executado por chamadas, em caso de falha não terá um rollback completo do job.
	* '''Lógica mais completa com múltiplos acessos e contexto de rollback "único"''' - Em caso de lógica mais complexa que faça alterações em partes ou realize muitos acessos é recomendado criar um outro método auxiliar e chamado através de uma fachada para que o contexto seja criado desde o princípio e controlado de forma sólida. Para esses métodos, que não devem ser publicados na fachada, utilize a fachada privada '''BISFacadePrivate'''.		* '''Lógica mais completa com múltiplos acessos e contexto de rollback "único"''' - Em caso de lógica mais complexa que faça alterações em partes ou realize muitos acessos é recomendado criar um outro método auxiliar e chamado através de uma fachada para que o contexto seja criado desde o princípio e controlado de forma sólida. Para esses métodos, que não devem ser publicados na fachada, utilize a fachada privada '''BISFacadePrivate'''.

			=== Padrão de Nomenclarura ===

			Quando for necessário criar um método auxiliar para executar a tarefa do Job através da chamada da fachada privada. Utilize o mesmo nome do método que cria o job acrescido do sufixo "Background". Mesmo que a assinatura do método seja diferente (parâmetros e retornos diferentes). Assim fica fácil a identificação de ambos os métodos e evita confusões.

	== Interrompendo o Job ==		== Interrompendo o Job ==

Rodrigogml: /* Session Context do Job */

2022-02-12T14:51:14Z

Session Context do Job

← Edição anterior		Edição das 14h51min de 12 de fevereiro de 2022
Linha 37:		Linha 37:
	Para resolver isso há duas maneiras possíveis dependendo do trabalho a ser executado:		Para resolver isso há duas maneiras possíveis dependendo do trabalho a ser executado:
	* '''Poucos ou quase nenhum acesso de consulta ao banco de dados''' - Caso a lógica do Job não necessite muitos acessos a lógica pode ser colocada diretamente dentro da Thread e cada acesso que for abre uma nova chamada através dos métodos já existentes na Fachada. Tenha em mente que cada acesso tem o custo de chamada de fachada e criação do contexto. Além disso, a lógica não ficará completamente dentro do mesmo contexto, assim cada rollback só é executado por chamadas, em caso de falha não terá um rollback completo do job.		* '''Poucos ou quase nenhum acesso de consulta ao banco de dados''' - Caso a lógica do Job não necessite muitos acessos a lógica pode ser colocada diretamente dentro da Thread e cada acesso que for abre uma nova chamada através dos métodos já existentes na Fachada. Tenha em mente que cada acesso tem o custo de chamada de fachada e criação do contexto. Além disso, a lógica não ficará completamente dentro do mesmo contexto, assim cada rollback só é executado por chamadas, em caso de falha não terá um rollback completo do job.
	* '''Lógica mais completa com múltiplos acessos e contexto de rollback "único"''' - Em caso de lógica mais complexa que faça alterações em partes ou realize muitos acessos é recomendado criar um outro método auxiliar e chamado através de uma fachada para que o contexto seja criado desde o princípio e controlado de forma sólida.		* '''Lógica mais completa com múltiplos acessos e contexto de rollback "único"''' - Em caso de lógica mais complexa que faça alterações em partes ou realize muitos acessos é recomendado criar um outro método auxiliar e chamado através de uma fachada para que o contexto seja criado desde o princípio e controlado de forma sólida. Para esses métodos, que não devem ser publicados na fachada, utilize a fachada privada '''BISFacadePrivate'''.



	== Interrompendo o Job ==		== Interrompendo o Job ==

Rodrigogml: /* Criando o Job */

2022-02-12T14:38:45Z

Criando o Job

← Edição anterior		Edição das 14h38min de 12 de fevereiro de 2022
Linha 15:		Linha 15:
	job.start(); //inicia a tarefa		job.start(); //inicia a tarefa
	</syntaxhighlight>}}		</syntaxhighlight>}}



Linha 28:		Linha 29:
	Deve-se tomar cuidado quando esse objeto for enviado para outras partes do sistema, como por exemplo atravessar uma fachada, ou qualquer outra situação em que o objeto é clonado e não mais usada a mesma instância da memória. Nestes casos alterações no novo objeto não refletirão no objeto original.		Deve-se tomar cuidado quando esse objeto for enviado para outras partes do sistema, como por exemplo atravessar uma fachada, ou qualquer outra situação em que o objeto é clonado e não mais usada a mesma instância da memória. Nestes casos alterações no novo objeto não refletirão no objeto original.
	}}		}}


			== Session Context do Job ==

			Note que depois que o Job é disparado, a Thread principal do usuário é finalizada retornando o JobStatus para o usuário. Uma vez que a chamada é retornada o contexto de sessão do EJB é finalizado. Assim a thread do Job não conseguirá mais acessar o banco de dados ou outros recursos que dependam do contexto.

			Para resolver isso há duas maneiras possíveis dependendo do trabalho a ser executado:
			* '''Poucos ou quase nenhum acesso de consulta ao banco de dados''' - Caso a lógica do Job não necessite muitos acessos a lógica pode ser colocada diretamente dentro da Thread e cada acesso que for abre uma nova chamada através dos métodos já existentes na Fachada. Tenha em mente que cada acesso tem o custo de chamada de fachada e criação do contexto. Além disso, a lógica não ficará completamente dentro do mesmo contexto, assim cada rollback só é executado por chamadas, em caso de falha não terá um rollback completo do job.
			* '''Lógica mais completa com múltiplos acessos e contexto de rollback "único"''' - Em caso de lógica mais complexa que faça alterações em partes ou realize muitos acessos é recomendado criar um outro método auxiliar e chamado através de uma fachada para que o contexto seja criado desde o princípio e controlado de forma sólida.

Rodrigogml: /* JobMonitor */

2022-02-12T14:18:24Z

JobMonitor

← Edição anterior		Edição das 14h18min de 12 de fevereiro de 2022
Linha 72:		Linha 72:


	Note que no exemplo acima o '''.start()''' do job pode ser dado a qualquer momento. O job não precisa estar ~~sendo executado~~ para que todo o restante funcione.		Note que no exemplo acima o '''.start()''' do job pode ser dado a qualquer momento. O job não precisa estar em execução para que todo o restante funcione.

Rodrigogml: /* JobChecker */

2021-09-09T13:36:46Z

JobChecker

← Edição anterior		Edição das 13h36min de 9 de setembro de 2021
Linha 159:		Linha 159:


	~~Para suprir~~ a ~~necessidade de encontrar~~ o ~~Job em um JobMonitor de outra JVM,~~ é ~~possível criar~~ o '''~~JobChecker~~''' ~~passando~~ uma ~~implementação~~ do '''~~JobStatusSupplier~~''' que ~~seja responsável por realizar a ponte até~~ o ~~JobMonitor correto~~.		{{nota\|JobChecker é sempre chamado!\|Note que dependendo da velocidade em que a tarefa é terminada, o JobChecker pode ser iniciado depois que a tarefa já esteja no passo '''FINISHED''' ou '''EXCEPTION'''. Ainda assim é garantido que o método '''updateStatus(...)''' será chamado ao menos uma única vez.

			Quando o '''updateStatus''' for chamado e o passo do '''JobStatus''' recebido for '''FINISHED''' ou '''EXCEPTION''' esta será a última vez (ou única) que será chamado. Quando detectado que chegamos em um desses dois passos o '''JobChecker''' se encerra.}}


			== JobStatusSupplier ==

	~~{{nota\|JobChecker é sempre chamado!\|Note que dependendo da velocidade~~ em ~~que a tarefa~~ é ~~terminada,~~ o ~~JobChecker pode ser iniciado depois que a tarefa já esteja no passo~~ '''~~FINISHED~~''' ou '''~~EXCEPTION~~'''~~. Ainda assim é garantido~~ que o ~~método '''updateStatus(...)''' será chamado ao menos uma única vez~~.		Para suprir a necessidade de encontrar o Job em um JobMonitor de outro ClassLoader, é possível criar o '''JobChecker''' passando uma implementação do '''JobStatusSupplier''' que seja responsável por realizar a ponte até o JobMonitor correto.

	~~Quando o~~ '''~~updateStatus~~''' ~~for chamado e~~ o ~~passo do~~ '''~~JobStatus~~''' ~~recebido for '''FINISHED''' ou '''EXCEPTION''' esta será a última vez (ou única) que será chamado~~. ~~Quando detectado que chegamos em um desses dois passos~~ o ''~~'JobChecker~~''~~' se encerra~~.}}		O FW fornece uma implementação padrão '''JobStatusSupplierDefault''' que faz a ponte para o '''JobMonitor''' dentro do mesmo ClassLoader. Essa implementação também é utilizada internamente quando o JobChecker é instanciando passando ''null'' no argumento do Supplier.

			Já no BISVaadin, para que o JobChecker possa acessar as tarefas criadas no Core, é oferecida a implementação '''JobStatusSupplierBISImpl''' que faz a chamada através da fachada e questiona o '''JobMonitor''' do Core.

	= JobMonitorComponent =		= JobMonitorComponent =

Rodrigogml: /* Dentro do JobMonitor */

2021-09-09T12:43:45Z

Dentro do JobMonitor

← Edição anterior		Edição das 12h43min de 9 de setembro de 2021
Linha 96:		Linha 96:
	Dentro do JobMonitor, quando a tarefa se registrou, o JobMonitor cria um Timer de segurança que verifica se o Job não foi esquecido dentro do JobMonitor e não teve seu .start() chamado. Passado o tempo do timer (no momento 1h) se o Job não estiver sendo executado, forçaremos a limpeza do Job como um vazamento de recursos.		Dentro do JobMonitor, quando a tarefa se registrou, o JobMonitor cria um Timer de segurança que verifica se o Job não foi esquecido dentro do JobMonitor e não teve seu .start() chamado. Passado o tempo do timer (no momento 1h) se o Job não estiver sendo executado, forçaremos a limpeza do Job como um vazamento de recursos.

	Caso esteja rodando, faremos um Log de que a tarefa está demorando demais, tarefas do JobMonitor não devem ser demoradas desta forma, tarefas de manutenção devem ser executadas pelo Scheduler. JobMonitor se destina mais para tarefas do usuário que possam demorar um pouco mais que o desejado para deixar a tela travada, não para execuções de longo prazo desse jeito.		Caso esteja rodando, faremos um Log de que a tarefa está demorando demais, '''tarefas do JobMonitor não devem ser demoradas desta forma, tarefas de manutenção devem ser executadas pelo Scheduler. JobMonitor se destina mais para tarefas do usuário que possam demorar um pouco mais que o desejado para deixar a tela travada, não para execuções de longo prazo desse jeito'''.


	== Dentro do Job ==		== Dentro do Job ==

Rodrigogml: /* Ciclo de Vida do Job */

2021-09-09T12:42:09Z

Ciclo de Vida do Job

← Edição anterior		Edição das 12h42min de 9 de setembro de 2021
Linha 89:		Linha 89:
	# Iniciamos a tarefa disparando a Thread do job com '''job.start()''';		# Iniciamos a tarefa disparando a Thread do job com '''job.start()''';
	## Neste momento a Thread do Job começa a ser executada.		## Neste momento a Thread do Job começa a ser executada.
	# O método deve ~~(provavelmente)~~ retornar o '''JobStatus''' ou o '''jobUUID''' para que o Caller consiga acompanhar a tarefa e solicitar seu cancelamento.		# O método do usuário deve retornar o '''JobStatus''' ou o '''jobUUID''' para que o Caller consiga acompanhar a tarefa e solicitar seu cancelamento.


	== Dentro do JobMonitor ==		== Dentro do JobMonitor ==
Linha 96:		Linha 97:

	Caso esteja rodando, faremos um Log de que a tarefa está demorando demais, tarefas do JobMonitor não devem ser demoradas desta forma, tarefas de manutenção devem ser executadas pelo Scheduler. JobMonitor se destina mais para tarefas do usuário que possam demorar um pouco mais que o desejado para deixar a tela travada, não para execuções de longo prazo desse jeito.		Caso esteja rodando, faremos um Log de que a tarefa está demorando demais, tarefas do JobMonitor não devem ser demoradas desta forma, tarefas de manutenção devem ser executadas pelo Scheduler. JobMonitor se destina mais para tarefas do usuário que possam demorar um pouco mais que o desejado para deixar a tela travada, não para execuções de longo prazo desse jeito.


	== Dentro do Job ==		== Dentro do Job ==