We have multiple application contexts deployed on WildFly.
Is it possible to have a global session expiry across all deployed applications so that if 1 application's session state has not expired, the rest of the application's session state cannot expire? Could this be achieved through configuring Single Sign On?
We would like to have the same behaviour as a portal containing many portlets where there is a portal session scope that contains portlets with their own session scope. The session expiry would correspond to inactivity within the portal session scope.
Please let me know if anyone out there has achieved what I've described above (but not with a Portal architecture).
Every application sets its session timeout in the web.xml each of them maintains sessions for users independent of the other applications in the server and this is the behavior all Java EE application servers by my experience. That said, if you configure SSO i will advice you set the same session timeout for all these applications in the web.xml and you can be sure of common session timeout.
Related
We have started using infinispan cache with wildfly 13 in our web application. The web application is deployed in wildfly domain mode in a cluster of two node with one acting as master and the other as slave. In the application we have an admin feature, where the admin can terminate a user.
So what we want to do is add session objects to Infinispan cache and retrieve it and terminate it when required. I am aware that HttpSession object is not serializable hence it cannot be added to cache but every attribute added to the session object is serilizable so my question is, is there a workaround for the issue? Because right now we get a NotSerializable error when I try to add session to cache and it's also no longer possible to retrieve session from sessionId and terminate it due to security reasons.
There is no need to manually interact with the Infinispan cache: WildFly transparently supports full http session clustering with Infinispan. See https://docs.jboss.org/author/display/WFLY10/High+Availability+Guide
currently we are deploying to a cluster-scenario where we have 3 nodes (tomcat), all of them share their sessions via Hazelcast. We have an apache in front of these nodes as a loadbalancer.
curling our application, I see, that there are two session-cookies used:
1) is the usual tomcat session with a JSESSIONID
2) is the hazelcast-session with a hazelcast.sessionId
Is there any way to omit the JSESSIONID?
or
Is there any way to somehow "join" both?
Thanks in advance.
No, both are required in current implementation.
Hazelcast uses only hazelcast.sessionId as HttpSession.getId() and nearly everyplace to identify distributed session. But for some cases like failover Hazelcast uses both session identifiers (hazelcast.sessionId and JSESSIONID ) internally.
From Hazelcast documentation:
SessionId Generation
SessionId generation is done by Hazelcast Web Session Module if session replication is configured in the web application. Default cookie name for the sessionId is hazelcast.sessionId and this is configurable with cookie-name parameter in the web.xml file of the application. hazelcast.sessionId is just a UUID prefixed with “HZ” character and without “-“ character, e.g. HZ6F2D036789E4404893E99C05D8CA70C7.
When called by the target application, the value of HttpSession.getId() is the same as the value of hazelcast.sessionId.
I set up two equal tomcat servers that host the same web application (Sun RI JSF 2 / Tomahawk). For load balancing and fail-over scenarios I use an nginx server as reverse proxy delegating the request to the one or the other server. Right now one tomcat is defines as backup solution, so that tomcat server 1 handles all the requests. When I kill the process of tomcat 1, nginx nicely delegates the following requests to tomcat server 2. In order to reuse the session data I configured both tomcat servers to use memcached as session store. JSF is configured to store its state on the server.
Concerning the log files, this setup looks quite nice and session data is read and stored using the memcached server. This for example facilitates using the web application without the need to login again even if tomcat 1 has been shut down.
Nevertheless it seems as if my (session scoped) backing beans are not stored or being used after restoring the session respectively. Form fields are left empty that are supposed to be filled with the data from the session bean.
Is it possible to do such things with the mentioned technologies at all?
With memcached-session-manager and OWB you should use tomcat < 7.0.22 as in this version the notification of ServletRequestListeners got changed (which is the mechanism used by OWB for failover support).
I'm currently working on a new version of msm that works with OWB and tomcat >= 7.0.22.
I'm working with an application in jsf and continuously Delivery to Heroku. I'm new to both JSF and Heroku.
I don't know if it's possible but my wish is to be able to do minor updates on the application, deploy to Heroku but still let the sessions survive for the session scoped manage beans. I have set the State saving to be client in my web.xml but when I deploy the application to Heroku all the values in the manage beans are reset to their init values.
Does anyone know how to fix this? Thank you
On Heroku you need to externalize your session state (or preferably don't use session state, which unfortunately isn't an option with JSF). Configuring your app server to do this is usually pretty easy but it depends on which app server you are using. Here is how to do it with Jetty and MongoDB as the session store:
http://www.jamesward.com/2011/11/30/using-mongodb-for-a-java-web-apps-httpsession
I have gone through various books on stateful and stateless session bean and how they work. I want to know the real usage of these ejbs and advantages over using plain java classes. Basically when do you go for stateless ejbs and when do you go for stateful ejbs. I want a real time application.
the usage of these type of ejbs are usually in service layer as service classes.
EJB3 stateless and stateful bean are actually POJO (with some annotations) and they don't have any big difference with normal classes.
but in term of usage, they have some abilities that you can't find in normal classes like:
they can be called remotely (e.g. RMI protocol).
they can use application server context resources like DB Connection and Transactions.
stateless or stateful:
- if a task or process can be done in a single step (by a single method call) stateless is the right option
like a authentication process
- if a task needs a series of method calls (more than one) and you need to keep previous results to use them in next call, then go for stateful.
like a shipping process (select items, add/remove and then do the transaction)
http session or stateful?
ejbs can be served in application server and they may have different type of clients like a normal swing application or ..., so you can't relay on http session in these cases.
if your appserver and webserver are different (distributed) its not good idea keep data in http session and pass/getback it to/from app server (network overhead).
Stateless session bean are lightweight: they do not store information about a specific user. They are usually used in a static way. For example a client ask for a product information will communicate with a stateless session bean. ("You want the price of product 'YXZ', here you go!")
Stateful session bean however remember's the client information. They contains data about the user actions. For example, let's say a user go through a shopping cart. The steps will be stored in a stateful session bean (for example, user it at the payment step).
You really need both type of session bean in any website. Unless you web site is so basic that anything can be done with stateless session bean (a read-only web site really).
Any web site that track a user through cookies, will need a stateful session bean. Be aware however that you can decide to put very little session information in a session bean and store that information in a database. But you still need some session management.
Developers prefer to maintain state in web layer in modern enterprise applications. I have never seen a real world web application using Stateful Session Bean. It is a scalability issue also.
An example is a shopping cart stateful session bean that tracks a client's product choices and can execute a sale when requested.