Kiosk Session Timeout Best Practice

Dear All,
I've noticed that user sessions are being timed out after about 3 hrs 20 minutes (presumably this is the default) so people coming in to work in the morning are having to start new sessions which really isn't practical with Citrix.
The users need to be able to leave a session in the evening and then pick it up again the following morning.
What are people using as a timeout value for Sun Ray sessions - 12 hours? 24 hours? What's the best thing to do? Will it cause problems if I have lots of sessions hanging around for that length of time?
Many thanks.
Chris

Similar Messages

ADF Faces : session timeout best practice

hi
I made these small modifications to the web.xml file in the SRDemoSample application:
(a) I changed the login-config from this ...
<login-config>
    <auth-method>FORM</auth-method>
    <form-login-config>
      <form-login-page>infrastructure/SRLogin.jspx</form-login-page>
      <form-error-page>infrastructure/SRLogin.jspx</form-error-page>
    </form-login-config>
</login-config>... to this
<login-config>
    <auth-method>BASIC</auth-method>
</login-config>(b) I changed the session-timeout to 1 minute.
<session-config>
    <session-timeout>1</session-timeout>
</session-config>Please consider this scenario:
(1) Run the UserInterface project of the SRDemoSample application in JDeveloper.
(2) Authenticate using "sking" and password "welcome".
(3) Click on the "My Service Requests" tab.
(4) Click on a "Request Id" like "111". You should see a detail page titled "Service Request Information for SR # 111" that shows detail data on the service request.
(5) Wait for at least one minute for the session to timeout.
(6) Click on the "My Service Requests" tab again. I see the same detail page as in (4), now titled "Service Request Information for SR #" and not showing any detail data.
question
What is the best practice to detect such session timeouts and handle them in a user friendly way in an ADF Faces application?
thanks
Jan Vervecken

Hi,
no. Here's the content copied from a word doc:
A frequent question on the JDeveloper OTN forum, and also one that has been asked by customers directly, is how to detect and graceful handle user session expiry due to user inactivity.
The problem of user inactivity is that there is no way in JavaEE for the server to call the client when the session has expired. Though you could use JavaScript on the client display to count
down the session timeout, eventually showing an alert or redirecting the browser, this goes with a lot of overhead. The main concern raised against unhandled session invalidation due to user
inactivity is that the next user request leads to unpredictable results and errors messages. Because all information stored in the user session get lost upon session expiry, you can't recover the
session and need to start over again. The solution to this problem is a servlet filter that works on top of the Faces servlet. The web.xml file would have the servlet configured as follows
1.     <filter>
2.         <filter-name>ApplicationSessionExpiryFilter</filter-name>
3.         <filter-class>
4.             adf.sample.ApplicationSessionExpiryFilter
5.         </filter-class>
6.         <init-param>
7.             <param-name>SessionTimeoutRedirect</param-name>
8.             <param-value>SessionHasExpired.jspx</param-value>
9.         </init-param>
10.     </filter>
This configures the "ApplicationSessionExpiryFilter" servlet with an initialization parameter for the administrator to configure the page that the filter redirects the request to. In this
example, the page is a simple JSP page that only prints a message so the user knows what has happened. Further in the web.xml file, the filter is assigned to the JavaServer Faces
servlet as follows
1.     <filter-mapping>
2.             <filter-name>ApplicationSessionExpiryFilter</filter-name>
3.             <servlet-name>Faces Servlet</servlet-name>
4.         </filter-mapping>
The Servlet filter code compares the session Id of the request with the current session Id. This nicely handles the issue of the JavaEE container implicitly creating a new user session for the incoming request.
The only special case to be handled is where the incoming request doesn't have an associated session ID. This is the case for the initial application request.
1.     package adf.sample;
2.
3.     import java.io.IOException;
4.
5.     import javax.servlet.Filter;
6.     import javax.servlet.FilterChain;
7.     import javax.servlet.FilterConfig;
8.     import javax.servlet.ServletException;
9.     import javax.servlet.ServletRequest;
10.     import javax.servlet.ServletResponse;
11.     import javax.servlet.http.HttpServletRequest;
12.     import javax.servlet.http.HttpServletResponse;
13.
14.
15.     public class ApplicationSessionExpiryFilter implements Filter {
16.         private FilterConfig _filterConfig = null;
17.
18.         public void init(FilterConfig filterConfig) throws ServletException {
19.             _filterConfig = filterConfig;
20.         }
21.
22.         public void destroy() {
23.             _filterConfig = null;
24.         }
25.
26.         public void doFilter(ServletRequest request, ServletResponse response,
27.                              FilterChain chain) throws IOException, ServletException {
28.
29.
30.             String requestedSession =   ((HttpServletRequest)request).getRequestedSessionId();
31.             String currentWebSession = ((HttpServletRequest)request).getSession().getId();
32.
33.             boolean sessionOk = currentWebSession.equalsIgnoreCase(requestedSession);
34.
35.             // if the requested session is null then this is the first application
36.             // request and "false" is acceptable
37.
38.             if (!sessionOk && requestedSession != null){
39.                 // the session has expired or renewed. Redirect request
40.                 ((HttpServletResponse) response).sendRedirect(_filterConfig.getInitParameter("SessionTimeoutRedirect"));
41.             }
42.             else{
43.                 chain.doFilter(request, response);
44.             }
45.         }
46.
47.     }
This servlet filter works pretty well, except for sessions that are expired because of active session invalidation e.g. when nuking the session to log out of container managed authentication. In this case my
recommendation is to extend line 39 to also include a check if security is required. This can be through another initialization parameter that holds the name of a page that the request is redirected to upon logout.
In this case you don't redirect the request to the error page but continue with a newly created session.
Ps.: For testing and development, set the following parameter in web.xml to 1 so you don't have to wait 35 minutes
1.     <session-config>
2.         <session-timeout>1</session-timeout>
3.     </session-config> Frank
Edited by: Frank Nimphius on Jun 9, 2011 8:19 AM

Cisco ISE and WLC Timeout Best Practices

I am fairly new to ISE. Our Cisco WLC is using 802.1x and ISE is configured for PEAP with all inner methods enabled.
I am looking for some guidance around where I should be configuring timeouts. There is a PEAP Session timeout in ISE, a session timeout on the WLC and a RADIUS reauthentication timeout that can be set in the Authorization profile results object in ISE.
Currently I have the WLC configured for its default 1800 second timeout and ISE PEAP timeout at the default 7,200 value.

I ended up answering my own question. The authorization session timeouts should be set in ISE if at all.
Once I removed the session timeout value from the WLC and used the re-auth value in the ISE policy I had less complaints about disconnects.
The session timeout on the PEAP settings has not caused any ill affects at it's default. The session resume has taken a huge load off of AAA though. Its worth turning on.

Session question; best practice

Hi,
One of our high profile application's queries/updates are served to user sessions. But we wanted to improve user query performance and reduce general database activity.
This piece of application cause an auto refresh to execute every 60 seconds. These queries execute against order tables looking for statuses on active orders, are user specific, and in some cases are not optimally tuned producing very high database buffer get and disk read activity. On average, 1,500 executions representing various flavors of these queries are executed hourly.
my questions are:
1) how can we get max performance ?
2) can we cache these queries for like every 30 secs ?
3) how can we cache ? so that user sessions would access the cache.
-sharma

well, you could load the data and put it in the application scope (in memory) with a timeout time so that it's not used after however long, in which case, a request would have to go to get the newer data from the DB.

What are default Zend Session handling best practices to prevent Cross Site Request Forgery?

I have enjoyed the David Powers book Adobe Dreamweaver CS5 with PHP: Training from the Source - and have put many of the examples into practice. I have a security related concern that may be tied to the Zend::Auth example in the book. While this is installed an working on my site:
<?php
$failed = FALSE;
if ($_POST) {
if (empty($_POST['username']) || empty($_POST['password'])) {
    $failed = TRUE;
} else {
    require_once('library.php');
    // check the user's credentials
    try {
      $auth = Zend_Auth::getInstance();
      $adapter = new Zend_Auth_Adapter_DbTable($dbRead, 'user', 'login', 'user_pass', 'sha1(?)');
      $adapter->setIdentity($_POST['username']);
      $adapter->setCredential($_POST['password']);
      $result = $auth->authenticate($adapter);
      if ($result->isValid()) {
        $storage = $auth->getStorage();
        $storage->write($adapter->getResultRowObject(array(
          'ID', 'login', 'user_first', 'user_last', 'user_role')));
        header('Location: /member/index.php');
        exit;
      } else {
        $failed = TRUE;
    } catch (Exception $e) {
      echo $e->getMessage();
if (isset($_GET['logout'])) {
require_once('library.php');
try {
    $auth = Zend_Auth::getInstance();
    $auth->clearIdentity();
} catch (Exception $e) {
    echo $e->getMessage();
Apparently, there is very limited protection against Cross Site Request Forgery, where the resulting SessionID could be easily hijacked? I am using the Zend Community edition (I have 1.11.11).     I have an observation from a client that this authentication is not up to snuff.
To boil it down:
1. Is there a Zend configuration file that might have some settings to upgrade the Session and or authentication security basics? I'm wondering specifically about the settings in /library/Zend/session.php? Ie secure the session against a changing user IP, and invoking some other session handling stuff (time-out etc).
2. If I understand it correctly, "salting" won't help with this, unless it's added/checked via a hidden POST at login time?
Ideally, the man himself, David Powers would jump in here - but I'll take any help I can get!
Thanks!

Might ask them over here.
http://forums.asp.net/1146.aspx/1?MVC
Regards, Dave Patrick ....
Microsoft Certified Professional
Microsoft MVP [Windows]
Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

Request/session objects - Best Practice

I have a simple scenario which I think other people will recognise, and am wondering what the best pattern to use in JSF is:
I have a summary page which displays orders for the current user in a dataTable. This has a backing bean called orders.
When the user clicks on an order, it calls an action on the orders object which fetches the specific order from the database and navigates to a second page to display details about the order.
I don't mind the orders object being a session bean, but I don't really want the order bean to be session, it needs to be a request bean.
How do I place the order bean somewhere so that it is a request bean on the second page?
In ASP.NET I could place it in the ViewState before transferring control to the second page, or temporarily put it on the session, then pull it off the session when the second page loads the first time.
The problem with putting the order object in the session is that it never goes away, and might be confused if the user has multiple browser windows open trying to look at 2 orders at the same time.

Here's the way I do this kind of thing.
In this case, I'd have a session bean called orders. It's got an orders property that will return all the orders for display in a dataTable. It's got a reference to a session-scoped bean that contains the id of the currently selected order. When the user selects an order (typically by clicking a commandLink) the id of the selected order is set in a session scoped bean called orderDetailsOptions and the user is navigated to the order details page. I'd have a Refresh button on the page that causes the orders to be reloaded.
public class OrdersBean {
private OrderDetailsOptionsBean orderDetailsOptions;
private DataModel orders;
private void reset() {
    orders = null;
public OrdersBean() {
    reset();
public void setOrderDetailsOptions( OrderDetailsOptionsBean orderDetailsOptions ) {
    this.orderDetailsOptions = orderDetailsOptions;
public DataModel getOrders() {
    if ( orders == null ) {
      ResultSet rs = doQuery();
      orders = new ResultDataModel( ResultSupport.toResult( rs ) );
    return orders;
/* Actions */
public String orderSelected() {
    Map row_data = (Map) orders.getRowData();
    String order_id = orders.get( "orderId" );
    orderDetailsOptions.setOrderId( order_id );
    reset();
    return "toOrderDetails";
public String refresh() {
    reset();
    return "success";
}The OrderDetailsOptionsBean for the session holds the id of the currently selected order.
public class OrderDetailsOptionsBean {
private String order_id;
public void setOrderId( String order_id ) {
    this.order_id = order_id;
public String getOrderId() {
    return order_id;
}The OrderDetailsBean is a request bean to get the details for the selected order.
public class OrderDetailsBean {
private OrderDetailsOptionsBean options;
private String order_id = null;
private Map fields = null;
public void setOptions( OrderDetailsOptionsBean options ) {
    this.options = options;
public String getOrderId() {
    if ( order_id == null ) {
      order_id = options.getOrderId();
public Map getFields() {
    if ( fields == null ) {
      getOrderId();
      // Do the query.
    return fields;
}Then here's what's in faces-config for this:
<managed-bean>
<managed-bean-name>orders</managed-bean-name>
<managed-bean-class>OrderBean</managed-bean-name>
<managed-bean-scope>session</managed-bean-scope>
<managed-property>
    <property-name>orderDetailsOptions</property-name>
    <property-class>OrderDetailsOptionsBean</property-class>
    <value>#{orderDetailsOptions}</value>
</managed-property>
</managed-bean>
<managed-bean>
<managed-bean-name>orderDetailsOptions</managed-bean-name>
<managed-bean-class>OrderDetailsOptionsBean</managed-bean-name>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
<managed-bean-name>orderDetails</managed-bean-name>
<managed-bean-class>OrderDetailsBean</managed-bean-name>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
    <property-name>options</property-name>
    <property-class>OrderDetailsOptionsBean</property-class>
    <value>#{orderDetailsOptions}</value>
</managed-property>
</managed-bean>
<navigation-rule>
<from-view-id>orders.jsp</from-view-id>
<navigation-case>
    <from-outcome>toOrderDetails</from-outcome>
    <to-view-id>orderDetails.jsp</to-view-id>
    <redirect />
</navigation-case>
</navigation-rule>

Session Data - best practice

Hi,
          We are designing a Servlet/JSP based application that has a web-tier
          separate from the middle tier.
          One of our apps have a lot of user inputs, average 500k and upto 2MB of data
          in the request.
          We do not have a way of breaking this application up (i.e the whole 2MB form
          data must be posted at ome time).
          We have 2 solutions and want to know what is the better one and wahy ...
          1. Use session and store all the information in the session.
          2. use Javascript to assemble all the data and submit it at one time.
          I prefer #2 because I don't want to use sessions and also becuase I don't
          want to use a database on the web-tier....
          Please help me explain to my cpollegues who are convinced that we have to
          use sessions to store this data..
          -JJ


I'm not overly familar with Weblogic clustering, but I assume it is similar in concept to OC4J clustering. The thing that you need to be aware of is that any object stored in HttpSession needs to be completely serializable. The LibrarySession that you create/obtain for a user cannot be serialized. Thus you need to come up with a technique that allows a user to obtain the same librarysession instance from whatever store it may be across multiple requests.
CM SDK, Files, Content Services typically achieve high availability through use of multiple midtiers with Big IP in front. Our out-of-box applications do not make use of OC4J clustering.
thanks,
matt.

Handle Session Timeout

I am using JDeveloper 11.1.1.6.
I am trying to gracefully handle session time outs in ADF. My application has been experiencing the 'canned' ADF session timeout popup when I am logged into my application and the session has timed out. That same popup is rendered even if I am sitting at my login page but haven't signed in.
I have followed Frank Nimphius's guidance as explained in the following forum to have my application re-direct to the login page after session timeout. That works great thanks to his well detailed document.
ADF Faces : session timeout best practice
The concern I have now is if I am sitting at my login page and my session times out, the application stays at the login page. I now type my credentials and click log in. Because the application thinks my session is timed out, I am taken back to the login page. Ideally I wouldn't think the login page would hold a session. Do you have any guidance on how I can get around this.

Hi,
what about using programmatic login, in which case the login form is part of a public page (see http://www.oracle.com/technetwork/issue-archive/2012/12-jan/o12adf-1364748.html for an example you can download)
Frank

Best practice for keeping a mail session open in web application?

Hello,
We have a webmail like application where users login with their IMAP credentials, then are taken to an authenticated area of the site where they can manage different things about their email account.
Right now the application is opening and closing a mail store connection (via a new javax.mail.Session) for each page load based on the current logged in user credentials. To me this seems like it would be a bad practice to keep opening and closing a connection each page load.
Are there any best practices for this situation? It would be nice to be able to open the connection to the mail server on login, then keep that connection open until the person logs out, session expires, etc.
I can probably put the javax.mail.Session into the HTTP session, but that seems like it would break any clustering functionality of tomcat. This would be fine if the machine the user is on didn't fail, but id assume if they failed over to another the mail session would be gone. Maybe keeping the mail session in the http session, checking for a connection, then first attempting to reconnect with the logged in credentials before giving up would be a possiblity?
Any pointers would be appreciated

If you keep the connection open across pages, you're going to need to deal with
timeouts - from the http session and from the mail server.
If you don't keep the connection open, you're going to need to "resynchronize"
your view of the store/folder with each operation, in case the folder is modified
by another session.
The former is easier in the common cases, especially if you don't care how gracefully
you handle failures. The latter is more difficult in the common cases, but handles
failure better, and in particular handles clustering better. You'll need to measure it to
see if it meets your performance and scalability requirements. You may need to mix
the two approaches to get acceptable performance.

Best Practice for Handling Timeout

Hi all,
What is the best practice for handling timeout in a web container?
By the way, we have been using weblogic 10.3
thanks

Are you asking about this specific to web services, or just the JEE container in general for a web application?
If a web application, Frank Nimphius recently blogged a JEE filter example that you could use too:
http://thepeninsulasedge.com/frank_nimphius/2007/08/22/adf-faces-detecting-and-handling-user-session-expiry/
Ignore the tailor fitted ADF options, this should work for any app.
CM.

Sessions and Controllers best-practice in JSF2

Hi,
I've not done web development work since last using Apache Struts for its MVC framework ( about 6 years ago now ). So bear with me if my questions does not make sense:
SESSIONS
1) Reading through the JSF2 spec PDF, it mentions about state-saving via the StateManager. I presume this is also the same StateManager that it used to store managed-beans that are in @SessionScoped ?
2) In relation to session-scoped managed beans, when does a JSF implementation starts a new session ? That is, when does the implementation such as Mojarra call ExternalContext.getSession( true ) .. and when does it simply uses an existing session ( calling ExternalContext.getSession( false ) ) ?
3) In relation to session-scoped managed beans, when does a JSF implementation invalidate a session ? That is, when does the implementation call ExternalContext.invalidateSession() ?
4) Does ExternalContext.getSession( true ) or ExternalContext.invalidateSession() even make sense if the state-saving mechanism is client ? ( javax.faces.STATE_SAVING_METHOD = client ) Will the JSF implementation ever call these methods if the state-saving mechanism is client ?
CONTROLLERS
Most of the JSF2 tutorials that I have been reading on-line uses the same backing-bean when perfoming an action on the form ( when doing a POST or a GET or a post-back to the same page ).
Is this best practice ? It looks like mixing what should have been a simple POJO with additional logic that should really be in a separate class.
What have others done ?

gimbal2 wrote:
jmsjr wrote:
EJP wrote:
It's better because it ensures the bean gets instantiated, stuck in the session, which gets instantiated itself, the bean gets initialised, resource-injected, etc etc etc. Your way goes goes behind the scenes and hopes for the best, and raises complicated questions that don't really need answers.Thanks.
1) But if I only want to check that the bean is in the session ... and I do NOT want to create an instance of the bean itself if it does not exist, then I presume I should still use ExternalApplication.getSessionMap.get(<beanName>).I can't think of a single reason why you would ever need to do that. Checking if a property of a bean in the session is populated however is far more reasonable to me.In my case, there is an external application ( e.g. a workflow system from a vendor ) that will open a page in the JSF webapp.
The user is already authenticated in the workflow system, and the external system from the vendor sends along the username and password and some parameters that define what the request is about ( e.g. whether to start a new case, or open an existing case ). There will be no login page in the JSF webapp as the authentication was already done externally by the workflow system.
Basically, I was think of implementing a PhaseListener that would:
1) Parse the request from the external system, and store the relevant username / password and other information into a bean which I store into the session.
2) If the request parameter does not exist, then I go look for a bean in the session to see if the actual request came from within the JSF webapp itself ( e.g. if it was not triggered from the external workflow system ).
3) If this bean does not exist at all ( e.g. It was triggered by something else other than the external workflow system that I was expecting ) then I would prefer that it would avoid all the JSF lifecycle for the current request and immediately do a redirect to a different page ( be it a static HTML, or another JSF page ).
4) If the bean exist, then proceed with the normal JSF lifecycle.
I could also, between [1] and [2], do a quick check to verify that the username and password is indeed valid on the external system ( they have a Java API to do that ), and if the credentials are not valid, I would also avoid all the JSF lifecycle for the current request and redirect to a different page.

Row level security with session variables, not a best practice?

Hello,
We are about to implement row level security in our BI project using OBIEE, and the solution we found most convenient for our requirement was to use session variables with initalization blocks.
The problem is that this method is listed as a "non best practice" in the Oracle documentation.
Alternative Security Administration Options - 11g Release 1 (11.1.1)
(This appendix describes alternative security administration options included for backward compatibility with upgraded systems and are not considered a best practice.)
Managing Session Variables
System session variables obtain their values from initialization blocks and are used to authenticate Oracle Business Intelligence users against external sources such as LDAP servers or database tables. Every active BI Server session generates session variables and initializes them. Each session variable instance can be initialized to a different value. For more information about how session variable and initialization blocks are used by Oracle Business Intelligence, see "Using Variables in the Oracle BI Repository" in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition.
How confusing... what is the best practice then?
Thank you for your help.
Joao Moreira

authenticating / authorizing part is take care by weblogic and then USER variable initialized and you may use it for any initblocks for security.
Init block for authenticating / authorizing and session variables are different, i guess you are mixing both.

Connect JavaFx(Applets) to J2EE - best practice & browser session

Hi there,
Im new to JavaFX and Applet programming but highly interested.
What I dont get at the moment is how you connect the locally executed code of the applet to your system running on a server (J2EE).
Of course there seem to be different ways but I would like to avoid using RMI or things like that because of the problem with firewalls and proxies.
So I would like to prefer using HTTP(s) connection.
And here my questions:
1.) Is there any best practice around? For example: using HTTP because of the problems I mentioned above. Sample code for offering java method via HTTP?
2.) Is there a possibility to use the browser session? My J2EE applications are normally secured. If the user opens pages he has to login first and has than a valid session.
Can I use the applet in one of those pages and use the browser environment to connect? I dont want the user to input his credentials on every applet I provide. I would like to use the existing session.
Thanks in advance
Tom

1) Yes. If you look at least at the numerous JavaFX official samples, you will find a number of them using HttpRequest to get data from various servers (Flickr, Amazon, Yahoo!, etc.). Actually, using HTTP quite insulates you from the kind of server: it doesn't matter if it run servlets or other Java EE stuff, PHP, Python or other. The applet only knows the HTTP API (GET and POST methods, perhaps some other REST stuff).
2) It is too long since I last did Java EE (was still J2EE...), so I can't help much, perhaps somebody will shed more light on the topic. If the Web page can use JavaScript to access this browser session, it can provide this information to the JavaFX applet (JS <-> JavaFX communication works as well as with Java applets).

RD Session Host lock down best practice document

Hello,
I am currently working on deploying an RDS Farm. My farm has several RD Session host servers. Today I learned that you can do some bad things to the RD Session hosts, if a user presses
CTRL + Alt + End when having a open session. I locked all of this down using different GPOs which include disabled access task manager, cmd, locking the server, reboot and shutdown etc.
However, this being sad how would I know what else to lock down since I am new to this topic. I tried to find some Microsoft document about best practices what should be locked down but I wasn’t
successful and unfortunately a search in the forum did not bring up anything else.
With all the different features and option Windows Server 2008 R2 has I do not even know where to start.
Can some please point me into the right direction.
Thank you
Marcus

Hi,
The RD Session host lock down best practices of each business is different, every enterprise admin can only to find the most suitable for their own solutions based on their IT infrastructure.
I collected some resource info for you.
Remote Desktop Services: Frequently Asked Questions
http://www.microsoft.com/windowsserver2008/en/us/rds-faq.aspx
Best Practices Analyzer for Remote Desktop Services
http://technet.microsoft.com/en-us/library/dd391873(WS.10).aspx
Remote Desktop Session Host Capacity Planning for 2008 R2
http://www.microsoft.com/downloads/details.aspx?FamilyID=CA837962-4128-4680-B1C0-AD0985939063&displaylang=en
RDS Hardware Sizing and Capacity Planning Guidance.
http://blogs.technet.com/iftekhar/archive/2010/02/10/rds-hardware-sizing-and-capacity-planning-guidance.aspx
Technical Overview of Windows Server® 2008 R2 Remote Desktop Services
http://download.microsoft.com/download/5/B/D/5BD5C253-4259-428B-A3E4-1F9C3D803074/TDM%20RDS%20Whitepaper_RC.docx
Remote Desktop Load Simulation Tools
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=c3f5f040-ab7b-4ec6-9ed3-1698105510ad
Hope this helps.
Technology changes life……

BC4J ApplicationModule - best practice in Stateful web application?

When writing a stateful web application that uses BC4J framework as the model, what is considered best practice in using the Application Module. Is it okay to store an AM instance in a HttpSession, or should we opt for the features explained in the BC4J Pooling samples, which uses the SessionCookie interface?
Tips/Tricks/Pitfalls information welcome
Thx,

When writing a stateful web application that uses BC4J framework as the model, what is considered best practice in
using the Application Module. Is it okay to store an AM instance in a HttpSession, or should we opt for the features
explained in the BC4J Pooling samples, which uses the SessionCookie interface? Best practice is to store the SessionCookie (an ApplicationModule handle) as demonstrated in the pooling sample.
This will allow many advantages including scalable state management support, timeout support, and
failover / clustering support.
Caching the ApplicationModule directly can be dangerous because:
1. The AM is not serializable which could result in serialization exceptions if the servlet container were distributable.
2. The AM does not responsd to timeout which could result in memory leaks if the AM is not explicitly returned to the
pool at the end of each request.
3. For stateful applications the memory consumed by each AM could be significant. Even if the AM were correctly
released to the pool upon session timeout it would still have consumed that memory up to that point. Using the
SessionCookie along with state managed release allows for scalable state management.
Tips/Tricks/Pitfalls information welcome
Thx,

Kiosk Session Timeout Best Practice

Similar Messages

Maybe you are looking for