New session in JSP?

Question

I'm currently working in a project that's basically a search-engine. The
          application is running on BEA's WebLogic server and the logic is placed in
          JavaBeans and EnterpriseJavaBeans. The JavaBeans that I access from my
          JSP-pages has the scope set to 'session'.
          As long as every user runs the application in different webbrowsers
          everything is fine, but if I open a second window (pressing Ctrl+N in IE) it
          seems like I'm stuck in the same session which means that I've got two
          references to the same object of my JavaBean.
          The outcome is that I either get the same result from two different querys,
          or that my application crashes. The server executes the querys in different
          threads, but since the EJB that holds the result is a stateful sessionbean
          the result is dependet on the last query.
          Are there any way of detecting that a request is made from a new window in
          the same browser (http-headers?), and creating a new session? Are there any
          way at all to force a client into a new session?
          /Johan
          

Answer 1

          "Johan Kindgren" <[email protected]> wrote in message
          news:[email protected]...
          > The database that we searching in contains about one million rows in
          several
          > tables, and the design-specification we've got demands that 90% of the
          > querys should return a result within three seconds, from anywhere in the
          > world.
          > Our idea to solve this is to divide the application into three layers,
          where
          > the first one is the JSP and JavaBeans. The middle layer is our stateful
          > sessionbean and the last is an stateless entitybean that executes the
          > querys to the database. When a query is made, the entitybean returns an
          > array of id's to the stateful sessionbean that match the query, and
          > sessionbean then retreives details from the database in batches of 15
          > records.
          > With this design it takes less than half a second to retreive the next
          batch
          > by making a query from id's, instead of making a query from a name (which
          in
          > worst case can take up to a minute right now, we have not optimized the
          > database yet).
          >
          > The JavaBean that I use in the JSP-pages creates a connection to the
          > sessionbean, and this connection is kept throughout the session.
          To fix your initial problem, you should assoicate your stateful session
          beans with a HTTP request rather than a HTTP session. This will get around
          your current problems (crashes & synchronisation). Or a more complex
          approach could be to remove the EJB from the HTTP session before you use it
          (so that no other request can use it at the same time).
          Browsers can and will make multiple concurrent requests with what appears to
          be (from the Servlet engines perspective) the same HTTP session - so don't
          associate a stateful session bean with a HTTP session. Associate it with a
          request instead. (In fact this is true of any EJB).
          >
          > If I understand your suggestion correct, we would have to skip the middle
          > layer. I suspect that we would have significant loss of performance in
          that
          > case. Are there any way to work around this? Any ideas in another design
          > that would eliminate this problem?
          Layering is often useful. The trick is to layer things correctly. I don't
          really have the bandwidth to understand your use cases correctly to
          formulate the correct architecture to follow. I'll give you a brief 30,000
          foot view of how I tend to do things...
          Briefly, I've never been terribly convinced of the value of entity beans at
          all. I personally think they are a bit of a mistake because they are remote.
          I far prefer the JDO idea which will hopefully replace entity beans one
          day.(http://access1.sun.com/jdo/) Generally the current thinking is that
          whether you use JDBC, JDO or Entity Beans - they should be wrapped inside
          session beans anyway. So from your layering perspective, entity beans are
          implementation detail inside the session beans layer.
          Mostly the client side wants go get 'data objects' back from queries which
          can then be used to do other navigations / queries / operations. It also
          helps to have client side helper beans to abstract the complications of
          using session beans (handling lookups, pooling, timeouts etc.).
          So the layers I prefer to focus on are
          Server side: Session beans - implementation I don't care - maybe internally
          using entity beans or JDBC or JDO. These should be stateless wherever
          possible. Should return Java beans to clients.
          Client side: Java beans - wrap use of session beans
          (timeout/pooling/creation stuff and sesion bean API). These client side Java
          beans often pass client side state (e.g. user id) into sesssion bean methods
          to allow the session beans to be stateless. Usually the client side will
          include Servlets, JSP, custom JSP tags here too.
          The Session beans on the server side may be split into the main stateless
          session beans that do most of the work with some small stateful session
          beans for doing things like query paging etc - though I've often found its
          easy to do this in stateless beans with a clever caching model.
          > The application will serve about 30 concurrent users, but there are a tota
          l
          > of 400 users.
          Though the same user may use multiple web browser windows on a desktop, so 1
          real user can become several concurrent users.
          J.
          James Strachan
          =============
          email: [email protected]
          web: http://www.metastuff.com