Question

I have an application which processes IQ stanzas via smack (eventbased java library). We now switch from vanilla Tomcat to glassfish 3.1 and i would like to switch to ejb 3.1.

@Stateless
public class DispatchIQService {
    private static Logger log = Logger.getLogger(DispatchIQService.class);

    @PersistenceContext(unitName="hq")
    private EntityManager em;

    ....

    public void process(XMPPConnection connection, IQ rawRequest) {
    log.debug("Raw Provider IQ: " + rawRequest.toXML());

    RawResponse answer = null;

    try{
        StateWrapper state = new StateWrapper(em, connection, rawRequest);

        // parsing raw xml from request
        rawRequest.parse();
        // processing action
        answer = rawRequest.dispatchAction(state);

Due to the eventbased library i get in the correct object for each request. The StateWrapper is a old construct to pass the em, request and the connection through the message processing. I want to remove this asap by ejbs and dependency injection.

With rawRequest.dispatchAction(state) i pass the control to the request object to lookup the Facade Service and begin with the business logic.

@Override
public RawResponse dispatchAction(StateWrapper state) {
    ModelFacade modelFacade = Core.lookup(ModelFacade.class);
    return modelFacade.listModels(state, childElement.getIds());
}

Core.lookup just makes an jndi lookup to get the needed Bean. In this bean i can inject the em.

@Stateless
public class ModelFacade {

    @PersistenceContext(unitName="hq")
    private EntityManager em;

    ... 
public RsModelListIQ listModels(StateWrapper state, List<Long> list) { ...

My question is: Is this em running unter the same transaction like the em from DispatchIQService?
How can i check it? The adress of the em?

best regards
m

Answer 1

As long as you’re in the same transaction, then the injected EntityManager in both instances will refer to the same “JPA transaction context”. Containers typically implement this by injecting an EntityManager proxy that implements each method by looking at the transaction thread context and then re-dispatching to a per-transaction EntityManager. You can test my assertion by making an update to an entity in DispatchIQService and then requerying the entity in ModelFacade to ensure the update is still there.