So you suggest to:
- Stick with the OSIV pattern I'm using
- Optimize by
- looking at the database requests
- use cache:
* on the view level using oscache,
* second level caching where this makes sence and
* create custom cache where this is necessary.
Does this makes sence to everyone for a webapp that must be able to scale,
with a lot of public pages and actions and around 30 entities.
Regards
Morten Matras
2009/6/9 VANKEISBELCK Remi <r...@rvkb.com>
> Yeah OSCache is great, I abuse of it too... It can really boost up
> your app, and it's so easy to use it.
>
> And to be honest, I never bothered about the OSIV opening a tx even to
> serve a cached page. Again, unless you have issues, it's premature
> optimization IMO...
>
> Cheers
>
> Remi
>
> 2009/6/9 Morten Matras <morten.mat...@gmail.com>:
> > Hi Remi
> >
> > Thanks.
> >
> > The filter works for *.action only now - so it should be for
> stripes-actions
> > only.
> >
> > You're right about the caching in the view part. This is something I've
> > considered looking into next.
> >
> > oscache enables us to cache parts of a .jsp page very easily, so this can
> > allow us to avoid heavy queries that takes a lot of time to process.
> >
> > The oscache filter is placed before the hibernate filter, but I still
> think
> > I need to cache complete actions to make it work. I'll have a look at
> that.
> >
> > Morten
> >
> > 2009/6/9 VANKEISBELCK Remi <r...@rvkb.com>
> >>
> >> 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
> >> >
> >> >
> >
> >
> >
> > --
> > 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
> >
>
--
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
