We are using the 7.5 Mid Tier on WebSphere which supports session data replication between different instances of the app server. I am not aware of any user-visible issues that we had with that feature turned on. What we did notice, though, was that with it turned on, we were unable to manually flush the cache. We had to bounce the application servers (with both of them down at once) in order to get the cache to flush (cache persistence was turned off in the Mid Tier). Because of this, we turned the feature off so that we can manually flush the cache when we need to without having to take things down. So long as the load balancer keeps directing a given user to the same web/app server, then there are no issues with not replicating the session information among the app servers. In that case, the only time a user would have to log in again is if the web/app server they're on goes down, and they get redirected to another server. In general, that should be a rare occurrence.
Lyle From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Axton Sent: Wednesday, February 24, 2010 7:02 PM To: arslist@ARSLIST.ORG Subject: Re: Question about Session Affinity in Mid-Tier ** ARServer does not have a session per say as all authentication information is sent in each packet, but each ARServer does keep track of what licenses are allocated to a given account. This is why you can connect to a Remedy server through the user tool, bounce the Remedy server, and still use the same User tool session to access the Remedy server after the restart. The problem comes into play with floating licenses since a user can cause a floating license allocation on each ARServer. The mid-tier stores information specific to a session in session attributes; the session attributes are a function of the servlet container. That is why you must re-authenticate to the mid-tier if it is restarted while you have an active session. The session specifics are not serializable between multiple instances of a servlet container, the mid-tier application does not use a central store/replication method to serialize the objects between multiple instances, so session persistence is required for each connection to a given mid-tier server. The web server in use may (optionally) track sessions. Axton On Mon, Feb 22, 2010 at 10:18 AM, Garrison, Sean (Norcross) <sean.garri...@fiserv.com<mailto:sean.garri...@fiserv.com>> wrote: ** I have been doing some research and it appears that there are modules for apache that support session affinity between jsp engines. In other words you could have a front end apache server that stores all of the session info and connects to more than one jsp engine. If one of the engines goes down the session stored in the apache server remains and just connects to the other jsp engine helping to maintain the session for the user. Any issues would theoretically be invisible to the user and their session would remain. In our current environment users have to log in again if a mid-tier goes down for any reason. According to BMC on page 16 of the Mid-Tier configuration guide session affinity between jsp engines is not supported so I haven't bothered to open a ticket on it. My thinking is that it is due to the complexity of ARS. ARS needs a session and mid-tier needs a session. Although you may be able to keep your mid-tier session you lose the ARS session when you switch from one mid-tier to the next. Just in case I'm wrong I thought I would ask the question anyway. I was wondering if anyone has tried any hacks for this and got it working? Thanks, Sean _Platinum Sponsor: rmisoluti...@verizon.net<mailto:rmisoluti...@verizon.net> ARSlist: "Where the Answers Are"_ _Platinum Sponsor: rmisoluti...@verizon.net ARSlist: "Where the Answers Are"_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
