deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "PÉNET LUDOVIC" <l.pe...@senat.fr>
Subject Re: Extended EntityManager
Date Sun, 19 Apr 2015 20:55:12 GMT

Mark Struberg a écrit :
> Hi Ludovic!
>
> One possible solution is the locking as you already explained.
> Another one which worked well for me is to wrap JSF sendRedirect and close
> the EM in there. Would need to think how we can make this solution more
> broad and generally available.
> A third solution would theoretically be to ‚postpone‘ the redirect
> until the end of the request.
>
> This is surely an area where we could make it a LOT easier for Seam2 users
> (and other CRUD style projects) to get their apps ported over to CDI.
> So any ideas, objections and tricks are welcome :)
The three possibilities you mention look pretty similar to me. In all
cases, the goal is to have one and only one "JSF thread" at a time.

So, you just let go resource queries, other servlet queries but lock on
JSF queries.

In the implementation I use for "open view conversation" pattern, I
recognize "true" JSF requests by the fact they have a dswid parameter.

If this parameter is not set, I just pass the query to the next layer,
else I lock on the http session (and not the hibernate session as I
wrongly stated before).

Something like :

public class SequentialJSFQueriesFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
            FilterChain chain) throws IOException, ServletException {
        HttpServletRequest httpreq = (HttpServletRequest)request;
        String dswid = httpreq.getParameter("dswid");
        if (StringUtils.isEmpty(dswid)) {
            chain.doFilter(request, response);
            return;
        }


        HttpSession httpSession = httpreq.getSession();
        try {
            if (httpSession != null) {
                synchronized(httpSession) {
                    chain.doFilter(request, response);
                }
            }
        } catch(...) {
	  /// ...
        }
    }
}

The performance impact is not that bad. Of course, it would be better
without locking, but keeping the same DB session also has its own
advantages. And it allows you to go the easy way, such as keeping DTOs and
serializing them in the session. You can heavily use features such as
cascading operations without fearing horrible side effects - those who one
day "merged" objects in a complex hierarchy, then "updated" them and
accidentally deleted dozens of "cascading dependencies" know what I mean.
:->

And, well, again, if you know you are coding a demanding application, with
a high workload, a need for replication, and so on, you just don't go that
way. :-)

Of course, a custom implementation can add the little bells and whistles
some application needs, still to go the easy way. In my case, I also
handle for instance a "nokeepsession" parameter, which I use to invalidate
the http session once the request has been processed. Some of my
applications are used to batch generate thousands of static pages. With
this kind of simple trick, I have an easy mean to quickly close useless
http sessions.

Ludovic

|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|


Mime
View raw message