Hi Morten,
The "/*" mapping for the filter is good for development, but it could
be a problem in production, as you'll open a session/tx for each
incoming request, even those GETting images, javascripts and the like,
which is probably not what you want.
The mapping of the OSIV filter should be done for URLs that need
access to the db only. This would avoid opening sessions/tx for
nothing...
The page caching mechanism is great to improve performance, but
depending on how you implement it, it might not completely avoid to
open session/tx at each request.
For instance if you're using the oscache tags in your JSP, then the
OSIV filter will still open session/tx : the tag works in the view, so
the OSIV filter has already been invoked. That's why, as Richard
pointed out, the ordering of the filters is crucial.
If you wanted really smart session/tx handling a la OSIV using a
filter, you'd probably have to make your filter smarter. Depending on
the incoming requests, it'd decide to open a session for the thread,
or not. You'd probably do this using a rule engine btw (JRules ftw
:P)...
But I doubt you already need such kind of features. Again, if your app
used to work, why bothering changing anything ? Have you ran a
profiler ?
Cheers
Remi - premature optimization...
2009/6/9 Morten Matras <kodekon...@gmail.com>:
> Hi Richard and the rest of you.
>
> You're quite right the filter looks similar to this:
>
> <filter-mapping>
> <filter-name>
>>
>> TLSessionManagementFilter</filter-name>
>> <url-pattern>/*</url-pattern>
>> <dispatcher>REQUEST</dispatcher>
>> </filter-mapping>
>
> Actually it looks like this:
>
> <filter-mapping>
> <filter-name>HibernateFilter</filter-name>
> <servlet-name>StripesDispatcher</servlet-name>
> <dispatcher>REQUEST</dispatcher>
> </filter-mapping>
>
> <servlet-mapping>
> <servlet-name>StripesDispatcher</servlet-name>
> <url-pattern>*.action</url-pattern>
> </servlet-mapping>
>
> But how do I avoid that if I want to display dynamic content on public
> pages?
>
> I've added a cache mechanism on the view level (oscache) and hope that can
> be used to avoid attacks.
>
> Regards
>
> Morten
>
> 2009/6/8 Richard Hauswald <richard.hausw...@googlemail.com>
>>
>> Hi Remi,
>> I agree with you: Using DTO is mostly writing code twice.
>> Unfortunately there are situations where you can not avoid using DTOs
>> - luckily this happens not often.
>>
>> Using the domain model at the web tier is IMHO the right way. I'm
>> working on models with 100+ domain objects persisted in a database so
>> using DTO's would be very time consuming. But I don't understand why
>> using domain models means using OSIV.
>>
>> Also lazy loading makes sense at some points, lazy loading over a
>> collection of 20+ items is very time consuming since this requires 21+
>> queries to the database. Databases are the bottle neck of the most
>> data driven applications so spending 10 minutes to write and test a
>> hql query is worth the effort.
>>
>> Another problem of OSIV is that you loose the control over connection
>> handling. What if you need to open 10 db connections? The chance is
>> high that a performance enthusiast is using the one opened by the
>> filter and opening the remaining 9 in another way. Then he'd need to
>> close only the 9 he opened and let the filter close the remaining one.
>> Have fun understanding and testing this tasty bit of spaghetti. What
>> If you need multiple transactions? Or transactions spanned over 2 or 3
>> requests?
>>
>> This is the hibernate proposal for a DAO using a filter:
>> public ItemDAO() {
>> currentSession = HibernateUtil.getSessionFactory().getCurrentSession();
>> }
>> It hides its dependencies and makes it very hard to test the dao. This
>> is a real draw back of most filter based solutions. Hiding the whole
>> session and transaction dependencies might look very clean but this
>> effectively prevents easy testing. You will need to make heavy use of
>> reflections in order to prevent the call to this constructor.
>>
>> I think I didn't made my self clear with what I mean by DOS. A good
>> DOS attack needs a small amount of bandwidth to break the server down.
>> So it doesn't depend on a large bot net. The filter based solution
>> Morton linked is likely to be vulnerable to a database session DOS for
>> several reasons:
>> - Most people do a filter like the guy who wrote this comment:
>> ---
>> ...
>> Mapping the Filter like this in web.xml:
>> ...
>> <filter-mapping>
>> <filter-name>TLSessionManagementFilter</filter-name>
>> <url-pattern>/*</url-pattern>
>> <dispatcher>REQUEST</dispatcher>
>> </filter-mapping>
>> ...
>>
>> It won´t intercept the <jsp:include> internal requests - Avoiding the
>> premature session closing.
>> ...
>> ---
>> - Calls to Controllers which don't need database connections result in
>> opening, committing and closing a session and transaction.
>> - Calls to non existing pages will trigger the filter to open a db
>> connection. It's not a problem to let the server open 100 db
>> connections within one second. The only thing you need is a script
>> sending 100 GET's multi threaded without waiting for a response. It's
>> very hard to defend against a DOS using this leak. Of course you can
>> limit the amount a requests per second but you will have to do this
>> for the pattern /* - so all requests will be limited. Using
>> transactional services enables you to limit the requests per second to
>> public pages only easily.
>> - Most people don't know the details of filters and the order in which
>> they apply. So it's a very common mistake that the security filter is
>> executed after the OSIV filter. There are also use cases which will
>> force you to open db connections for public pages. I haven't seen a
>> sample using two different filters to make use of 2 different
>> connection pools :-(
>>
>> Regards,
>> Richard
>>
>> On Mon, Jun 8, 2009 at 7:14 PM, VANKEISBELCK Remi<r...@rvkb.com> wrote:
>> > Hi Morten,
>> >
>> > The proposed solutions are not using the same "pattern" that you use,
>> > and it might have serious drawbacks. I personnally stopped
>> > Transactional Services (that's the name of the method interceptor
>> > based solution that other posters have mentionned) in favor of Open
>> > Session In View a long, long time ago, and I don't see any compelling
>> > reason to get back to it...
>> >
>> > The key issue with Transactional Services is that the hibernate
>> > session is usually used once, for a method call, and not for the
>> > entire lifecycle of the http request. Objects passed to / returned
>> > from DAOs/Services are disconnected from the hb session.
>> > This sucks a lot as soon as you e.g. navigate lazy-loaded associations
>> > in your JSPs, which I do in almost every single JSP I write !
>> >
>> > Using Transactional Services looks compelling, but it clearly enforces
>> > a much more complicated design IMHO. You'll often end up with DTOs and
>> > the like, which IMHO are just writing code twice... You can't simply
>> > use your objects as they persisted magically. In that respect, OSIV
>> > provides a much more simple and effective programming model.
>> >
>> > The only issue with OSIV is that transactions / hibernate sessions are
>> > said to be "long lasting" : their lifecycle being the one of the http
>> > request. In school, they told you that a db transaction should always
>> > being, do only what it's supposed to do, and commit/rollback... In my
>> > experience, OSIV has always worked.
>> >
>> > And btw I don't agree with the DOS argument. Yes, the OSIV solution
>> > might not scale as good as the DTO one, and it's certainly easier to
>> > DOS an app that doesn't scale. But DOS isn't related to transaction
>> > management or anything, it's just about flooding the server. You can
>> > do this by many means, even when no db is involved at all...
>> >
>> > Anyway, in short, if I were you, I'd try to track down where my
>> > problem is (starting the app with a profiler might help), and fix it,
>> > especially if your app used to work with the same load on a different
>> > OS.
>> > Switching from OSIV to DTOs will be much more pain IMO.
>> >
>> > My 0.02
>> >
>> > Rémi
>> >
>> > 2009/6/2 Morten Matras <morten.mat...@gmail.com>:
>> >> Let's start with the questions for you:
>> >>
>> >> - How do I modify the filter below / use another (downloadable) filter
>> >> to
>> >> get a Hibernate Filter in my application that takes care of transaction
>> >> management and commit / rollback for me that works on a windows server
>> >> and
>> >> with an application that uses RedirectResolution?
>> >> - I consider switching to Stripernate (or whatever it's called now a
>> >> days).
>> >> Would that be a good idea?
>> >>
>> >>
>> >> In our application http://www.redantenna.com I've added a
>> >> HibernateRequestFilter inspired by: https://www.hibernate.org/43.html
>> >>
>> >> The architecture is something like: (MySQL - Hibernate - Tomcat - JSP)
>> >>
>> >> In this filter I open a new session on every request and either commit
>> >> it or
>> >> roll it back when the request is finished and the .jsp created and
>> >> returned.
>> >>
>> >> This has been working fine for years when deployed on linux machines,
>> >> but
>> >> this application is deployed on a windows machine causing this error:
>> >>
>> >> java.net.SocketException: No buffer space available (maximum
>> >> connections
>> >> reached?): JVM_Bind
>> >> at java.net.PlainSocketImpl.socketBind(Native Method)
>> >> at java.net.PlainSocketImpl.bind(Unknown Source)
>> >> at java.net.Socket.bind(Unknown Source)
>> >> at java.net.Socket.<init>(Unknown Source)
>> >> at java.net.Socket.<init>(Unknown Source)
>> >>
>> >> The application tries to connect to a mysql database (on another
>> >> server) and
>> >> is using a port to do that. When this error occurs nothing but a
>> >> complete
>> >> reboot of the server helps.
>> >>
>> >> I took a look at the source code of the hibernate filter and found that
>> >> the
>> >> session is never closed (unless that happens behind the scenes in
>> >> commit and
>> >> rollback of the transaction). I tried adding a session.close() to the
>> >> filter
>> >> but that caused errors when using RedirectResolution(...) in the
>> >> application.
>> >>
>> >> ----
>> >>
>> >> Source code of the doFilter method in the HibernateRequestFilter:
>> >>
>> >> public void doFilter(ServletRequest request,
>> >> ServletResponse response,
>> >> FilterChain chain)
>> >> throws IOException, ServletException {
>> >>
>> >> try {
>> >> sf.getCurrentSession().beginTransaction();
>> >> if (! sf.getCurrentSession().isConnected() ){
>> >>
>> >> sf.getCurrentSession().reconnect(sf.getCurrentSession().connection());
>> >> }
>> >> chain.doFilter(request, response);
>> >> } catch (StaleObjectStateException staleEx) {
>> >> throw staleEx;
>> >> } catch (Throwable ex) {
>> >> try {
>> >> if (sf.getCurrentSession().getTransaction().isActive())
>> >> {
>> >> log.debug("Trying to rollback database transaction
>> >> after
>> >> exception");
>> >> sf.getCurrentSession().getTransaction().rollback();
>> >> }
>> >> } catch (Throwable rbEx) {
>> >> log.error("Could not rollback transaction after
>> >> exception!",
>> >> rbEx);
>> >> }
>> >>
>> >> // Let others handle it... maybe another interceptor for
>> >> exceptions?
>> >> throw new ServletException(ex);
>> >> }
>> >> finally{
>> >> Session session = sf.getCurrentSession();
>> >> Transaction transaction = session.getTransaction();
>> >> //doCommit is an internal parameter telling the filter whether it
>> >> should
>> >> commit or rollback.
>> >> Boolean doCommit = (Boolean)
>> >> request.getAttribute("commit");
>> >> if (doCommit != null && doCommit.booleanValue()){
>> >> transaction.commit();
>> >> }
>> >> if (transaction.isActive()){
>> >> transaction.rollback();
>> >> }
>> >> session.close();
>> >> }
>> >> }
>> >>
>> >> ---
>> >>
>> >> With the last line: session.close(); the application is not able to
>> >> handle
>> >> RedirectResolution correctly. It causes an error saying that the
>> >> session is
>> >> closed. Without that the application get's the "maximum connections
>> >> reached?" error causing the server to stop working.
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Morten Matras
>> >> Consultant
>> >> Blob Communication ApS
>> >> Svendsagervej 42
>> >> DK-5240 Odense NØ
>> >> P: (+45) 76 6-5-4-3-2-1
>> >> W: www.blobcom.com
>> >> E: morten.mat...@gmail.com
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>> >> looking to deploy the next generation of Solaris that includes the
>> >> latest
>> >> innovations from Sun and the OpenSource community. Download a copy and
>> >> enjoy capabilities such as Networking, Storage and Virtualization.
>> >> Go to: http://p.sf.net/sfu/opensolaris-get
>> >> _______________________________________________
>> >> Stripes-users mailing list
>> >> Stripes-users@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/stripes-users
>> >>
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Crystal Reports - New Free Runtime and 30 Day Trial
>> > Check out the new simplified licensing option that enables unlimited
>> > royalty-free distribution of the report engine for externally facing
>> > server and web deployment.
>> > http://p.sf.net/sfu/businessobjects
>> > _______________________________________________
>> > Stripes-users mailing list
>> > Stripes-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Stripes-users mailing list
>> Stripes-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
> --
> Morten Matras
> Consultant
> Blob Communication ApS
> Svendsagervej 42
> DK-5240 Odense NØ
> P: (+45) 76 6-5-4-3-2-1
> W: www.blobcom.com
> E: morten.mat...@gmail.com
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
