Stato di passaggio tra i metodi EJB/@RequestScoped e @Stateless

Question

Ho un bean CDI @RequestScoped che voglio trasformare in un EJB per ottenere transazioni dichiarative. (Sono su EJB 3.1, Java EE 6)

Attualmente sto passando lo stato tra le subroutine, supponendo che l'istanza sia utilizzata solo in una singola richiesta. Se aggiungo @Stateless ora quell'ipotesi cambierebbe.

Ad esempio, voglio fare qualcosa di simile

@Stateless 
@Named 
@RequestScoped 
public class Foo { 
    private String var1; // can't use instance vars in @Stateless? 
    private String var2; 

    public void transactionForRequest() { 
    var1 = value; 
    var2 = value; 
    .... 
    subroutine(); 
    } 
} 

Suppongo che il sopra non lavoro-è corretto?

Sto contemplando due alternative:

• Uso @Stateful invece di @Stateless, insieme con @Named e @RequestScoped.
• Mantieni @Stateless e utilizza la mappa EJBContext.getContextData per sostituire le variabili di istanza.

Quale è meglio? E c'è qualche altra alternativa a cui non sto pensando? (Oltre ad aspettare Java EE 7 o passare a Spring. :-))

Answer 1

Mentre @Stateless, @Singleton e @MessageDriven riferimenti possono avere con ambito iniettato attraverso @Inject, non possono essere@RequestScoped o qualsiasi altro scopo. Solo il modello @Stateful è abbastanza flessibile da supportare gli ambiti. In altre parole, è possibile annotare la classe @Stateful bean stessa come @RequestScoped, @SessionScoped, ecc ..

In termini semplici @Stateless, @Singleton hanno fissato "ambiti" già. @Singleton è essenzialmente @ApplicationScoped e @Stateless potrebbe essere uno scope pronto come @InvocationScoped, se esistente. Il ciclo di vita di un bean @MessageDriven dipende interamente dal Connector che lo guida e, pertanto, non può disporre di un ambito definito dall'utente.

Vedi anche https://stackoverflow.com/a/8720148/190816

Answer 2

Se si utilizzano i fagioli stateless, si è responsabili di qualsiasi gestione dello stato e normalmente lo si farebbe nel livello dell'applicazione Web utilizzando HttpSession. E sì, non è possibile utilizzare le variabili di istanza come pool di bean privi di stato.

Answer 3

Vorrei andare con SFSB anziché SLSB. Vuoi tenere uno stato, quindi per me questa è l'informazione più importante - questo è un lavoro per Stateful EJB.

Inoltre, non credo che lo EJBContext#getContextData() ti possa aiutare. Per quanto mi ricordo, è valido solo per una durata di una chiamata. Pertanto, ogni invocazione di un metodo sul bean creerà nuova mappa dei dati di contesto (almeno è quello che mi aspettavo.)