Session handling on Java EE application

Question

I'm developing a system to process financial transactions received by client merchants systems & it is a replacement of existing system which we have purchased from a vendor. Client interface should invoke the user authentication & transaction processing screens from our system.

System functionality as follows,

1. Receive input parameters from the merchant's site
2. Validate it
3. Authenticate users (users are registered with our system & we should invoke our login screen)
4. Process transaction
5. Return status response to merchant

One the response is received client should validate the transaction data from the values reside in the session.

System overview can be depicted as follows,

( click here for full size image )

My problem is client could not retain the session once we are responding to the client. But the same functionality could be achieved by the system that we have purchased from the vendor (we don't have source code of this to analyse the internal coding structure). I hope something wrong with the way that we are responding to the client.

How can I overcome this problem?

We are using Java 1.4.2, Websphere application server

Answer 1

There are many things which can make a session disappear. I'd suggest to track them and verify if anything went right. This is easier to do if you understand how sessions work.

• Session has been timed out. This usually defaults to 30 minutes. This is confiugureable by <session-timeout> in web.xml where you can specify the timeout in minutes. You can implement a HttpSessionListener to track session creation and destroy using a logger.

• Session has forcibly been invalidated. This happens when the code calls HttpSession#invalidate() . This is trackable with a HttpSessionListener as well.

• Session cookie has been disappeared. Sessions are backed by cookies. If a session is been created, the server will add a Set-Cookie header with session ID. The client should send the same cookie back as Cookie header in all subsequent requests on the (context) path as specified in the Set-Cookie header. This is trackable in the HTTP traffic monitor ("Network" tab) of browser's builtin web developer toolset (press F12 in Chrome/Firefox23+/IE9+). Cookies are accessible for all webapps on the same cookie domain. Also, if ServletC2 runs on a different webapp context than ServletC1 , then it won't use the same session. Further, if the "server" webapplication runs on the same domain, then it's in theory able to wipe out all cookies of the "client" webapplication.

• The client doesn't support cookies. A well designed webapplication uses URL rewriting with jsessionid to track cookieless clients between requests on the same webapplication. But the second webapplication has to do the same when redirecting back to the first webapplication.