EJB 3.1 Transaction,EntityManager [英] EJB 3.1 Transaction, EntityManager

查看:128
本文介绍了EJB 3.1 Transaction,EntityManager的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个应用程序通过smack(事件基java库)处理智能节。我们现在从vanilla Tomcat切换到glassfish 3.1,我想切换到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);

//从请求中解析原始xml
rawRequest.parse();
//处理动作
answer = rawRequest.dispatchAction(state);

由于基于事件的库,我得到每个请求的正确对象。 StateWrapper是通过消息处理传递em,请求和连接的旧构造。我想通过ejbs和依赖注入删除这个asap。



使用rawRequest.dispatchAction(state),我将控件传递给请求对象,以查找Facade Service并从业务逻辑开始。

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

Core.lookup只是做一个jndi查找来获取所需的Bean。在这个bean中,我可以注入em。

  @Stateless 
public class ModelFacade {

@PersistenceContext(unitName =hq )
private EntityManager em;

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

我的问题是:这个em是否像DispatchIQService一样运行相同的事务?
我该怎么检查?最好的问题在于
m

解决方案

p>只要你处于同一个事务中,那么在这两个实例中注入的EntityManager将引用相同的JPA事务上下文。容器通常通过注入通过查看事务线程上下文然后重新分派到每个事务EntityManager来实现每个方法的EntityManager代理实现。您可以通过对DispatchIQService中的实体进行更新来测试我的断言,然后在ModelFacade中重新调用实体,以确保更新仍然存在。


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

解决方案

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.

这篇关于EJB 3.1 Transaction,EntityManager的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆