GWT请求工厂-从"ServiceLayerDecorator.isLive()"收集的多个查询; - 方法 [英] GWT Request Factory - Multiple queries for collection from the "ServiceLayerDecorator.isLive()" - method

查看:73
本文介绍了GWT请求工厂-从"ServiceLayerDecorator.isLive()"收集的多个查询; - 方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我遇到的问题是,每次我从gwt请求工厂检索一个集合时,都会对该集合中的每个实体调用"findEntity()"方法.这种"findEntity()"方法称为SQL数据库.

我发现发生这种情况是因为请求工厂检查了"ServiceLayerDecorator.isLive()"方法中每个实体的活动性"(也在此处进行了描述:解决方案

RequestFactory期望每个请求的会话模式具有 session ,以保证每个实体有一个实例(即使用缓存).

正确的 fix 是让isLive命中该缓存,而不是数据库.如果您使用JPA或JDO,他们应该免费为您这样做.重要的是请求"对此有何想法(如果发出了删除请求,则isLive应该返回false),而不是真正考虑了数据库中存储的内容,还要考虑其他因素用户可以同时完成.

话虽这么说,isLive仅用于驱动客户端的EntityProxyChange事件,所以,如果您不使用它们,那么像您一样无条件地返回true不会造成任何问题. /p>

I had the problem, that every time i retrieved a collection from the gwt request factory, there was the "findEntity()"-method called for every entity in that collection. And this "findEntity()"-method calls the SQL-Database.

I found out that this happens because request factory checks the "liveness" of every entity in the "ServiceLayerDecorator.isLive()"-method (also described here: requestfactory and findEntity method in GWT)

So i provided my own RequestFactoryServlet:

public class MyCustomRequestFactoryServlet extends RequestFactoryServlet {


    public MyCustomRequestFactoryServlet() {
        super(new DefaultExceptionHandler(), new MyCustomServiceLayerDecorator());

    }

}

And my own ServiceLayerDecorator:

public class MyCustomServiceLayerDecorator extends ServiceLayerDecorator {

    /**
     * This check does normally a lookup against the db for every element in a collection
     * -> Therefore overridden
     */
    @Override
    public boolean isLive(Object domainObject) {
        return true;
    }
}

This works so far and I don't get this massive amount of queries against the database.

Now I am wondering if I will get some other issues with that? Or is there a better way to solve this?

解决方案

RequestFactory expects a session-per-request pattern with the session guaranteeing a single instance per entity (i.e. using a cache).

The proper fix is to have isLive hit that cache, not the database. If you use JPA or JDO, they should do that for you for free. What matters is what "the request" thinks about it (if you issued a delete request, isLive should return false), not really what's exactly stored in the DB, taking into account what other users could have done concurrently.

That being said, isLive is only used for driving EntityProxyChange events on the client side, so if you don't use them, it shouldn't cause any problem unconditionally returning true like you do.

这篇关于GWT请求工厂-从"ServiceLayerDecorator.isLive()"收集的多个查询; - 方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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