Spring - @transacional-o que acontece em segundo plano?
-
Ouvi dizer que a Primavera cria uma classe proxy? Alguém pode explicar isto em mais profundidade. O que realmente reside nessa classe proxy? O que acontece à aula? E como posso ver a classe criada pela primavera
Também li Na Primavera. docs that:
Nota: dado que este mecanismo se baseia em proxies, apenas as chamadas do método 'externo' que chegam através do 'proxy' serão interceptadas. Isto significa que "auto-invocação", ou seja, um método dentro do objecto-alvo que invoca algum outro método do objecto-alvo, não levará a uma transacção real no tempo de execução, mesmo que o método invocado seja marcado com
@Transactional!
Fonte: http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html
Por que só as chamadas de método externo estarão sob transação e não os métodos de auto-invocação?
4 answers
Mas a um nível muito elevado, a Primavera cria proxies para as classes que declaram @transacional Sobre a própria classe ou sobre os membros. O proxy é praticamente invisível no tempo de execução. Ele fornece uma maneira para a Primavera injetar comportamentos antes, depois, ou em torno do método chama para o objeto sendo proxied. A gestão de transações é apenas um exemplo dos comportamentos que podem ser conectados. Os controlos de segurança são outros. E você pode fornecer o seu próprio, também, para coisas como madeireira. Então, quando você anota um método com @transacional , A mola cria dinamicamente um proxy que implementa a(s) mesma (s) interface (ões) que a classe que você anota. E quando os clientes fazem chamadas para o seu objeto, as chamadas são interceptadas e os comportamentos injectado através do mecanismo proxy.
A propósito, as transacções na EJB funcionam da mesma forma. Como você observou, através do mecanismo de proxy só funciona quando as chamadas vêm de algum objeto externo. Quando você faz uma chamada interna dentro do objeto, você está realmente fazendo uma chamada através da referência "isto", que contorna o proxy. No entanto, há formas de contornar esse problema. Eu explico uma abordagem em neste fórum post em que eu uso um Beanfactorypostprocessador para injectar uma instância do 'proxy' nas classes de "auto-referenciação" em tempo de execução. Guardo esta referência a uma variável membro chamada " me ". Então, se eu precisar fazer chamadas internas que requerem uma alteração no estado da transação do thread, eu dirijo a chamada através do proxy (por exemplo "me.someMethod () ".) O post do fórum explica em mais detalhes. Note que o Código Beanfactorypost Processor seria um pouco diferente agora, como foi escrito. na Primavera 1.x prazo. Mas espero que te dê uma ideia. Eu tenho uma versão atualizada que eu provavelmente poderia disponibilizar.Quando a Primavera carrega as suas definições de feijão, e foi configurada para procurar por anotações @Transacionais, irá criar estes objectos proxy à volta do seu verdadeiro feijão. Estes objetos proxy são instâncias de classes que são auto-geradas em tempo de execução. O comportamento padrão desses objetos proxy quando um método é invocado é apenas para invocar o mesmo método no bean "alvo" (ou seja, seu bean).
No entanto, os proxies também podem ser fornecidos com interceptores, e quando presentes estes os interceptores serão invocados pelo proxy antes que invoque o método do seu feijão-alvo. Para os feijões-alvo anotados com @Transactional, a mola irá criar um interceptor de Transaction, e passá-lo para o objecto proxy gerado. Então, quando você chama o método a partir do Código cliente, você está chamando o método no objeto proxy, que primeiro invoca o Interceptor de Transaction (que começa uma transação), que por sua vez invoca o método em seu feijão alvo. Quando a invocação terminar, o O interceptor de operações compromete / rola de volta a transacção. É transparente para o código do cliente. Quanto ao" método externo", se o seu feijão invoca um dos seus próprios métodos, então não o fará através do proxy. Lembra-te, a Primavera envolve o teu feijão no proxy, o teu feijão não tem conhecimento dele. Só as chamadas de "fora" do teu feijão passam pelo proxy. Isso ajuda?Client executa Proxy.method().
- o cliente chama um método sobre o alvo da sua perspectiva, e é silenciosamente interceptado pelo proxy
- Se um aspecto anterior estiver definido, o 'proxy' executá-lo-á
- Então, o método actual (target) é executado
- O Pós-retorno e o pós-lançamento são opcionais aspectos que são executado após a devolução do método e / ou se o método lançar um excepção
- Depois disso, o proxy executa o aspecto após (se definido)
- finalmente o 'proxy' regressa ao cliente que chama
(Eu fui autorizado a postar a foto na condição de que eu mencionei suas origens. Autor: Noel Vaes, sítio Web: www.noelvaes.eu)
A resposta mais simples é: em qualquer método que declare @transacional, o limite da transacção começa e termina quando o método terminar.
Se estiver a usar a chamada da APP, todos os commits estão dentro deste limite de transacção. Vamos dizer que você está salvando o entity1, entity2 e entity3. Agora, enquanto salvar o entity3 uma exceção ocorre então como entitiy1 e entity2 vem na mesma transação então entity1 e entity2 será rollback com entity3.
Transacção : (entity1.save, entity2.save, entity3.salvar). Qualquer excepção resultará na anulação de todas as transacções da APP com a DB. a transacção interna da App é utilizada na primavera.