Home/ Questions/Q 6543707
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T11:22:42+00:00

Given the fact that a Java EE application is to develop, which has the

  • 0

Given the fact that a Java EE application is to develop, which has the purpose of a chat server, I encountered some problems.

Clients should be able to connect using different connectors like HTTP, SOAP or AMF. Incoming requests need to be converted to unified, internal messages. Next, message driven beans call the business logic and return the result of the request to the specific connector.

Q1: Does that sound reasonable?

My question is how do I store the session information for each client. That would include connection data, timestamps, commands which need to be delivered etc.
Stateful Session Beans should be fine for this, because I need them just as long as a client is connected. However, the problem is to maintain a list of all beans to be able to pick the correct session for a new request.
I cannot link the SFSB reference to a HttpSession (as recommended elsewhere) because there are different connectors, not only HTTP clients.

Q2: What is the correct approach for that? A session manager, which performs a JNDI lookup to create a new SFSB and adds it to an internal list?

Q3: How would it work in a clustered environment? I see that SFSBs can be replicated to different nodes, but how to sync the session manager list?

Q4: Would you recommend session affinity in addition to a load balancer?

Thank you.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Q1: I guess. It depends on your requirements. Just don’t overcomplicate things. Go simple. And be aware that using things like message driven beans means asynchronous processing/responses and the chance for messages to fail or go to a system exception/dead letter queue.

    Q2: Generally you want to look up Java EE beans via JNDI. Makes life easier IMO. Perhaps you need a servlet or a stateless session bean or something in front as a “controller”? Then you can load the data for the stateful beans from the database when you need the data and/or write the data to the database when you do not need the bean anymore.

    Q3: Depends on how you configure your cluster and also on which application server you are using. Each server may possibly implement clustering/fail over/sync’ing, etc. differently. I would recommend reading up on your application server documentation to figure that one out. And/or post which application server you are using so others on this forum can recommend something. For example, we use IBM WebSphere Application Server, version 7.0.0.7, Network Deployment Edition. So in our case, we can set up replication of beans/objects between cluster nodes.

    Q4: I believe the answer is yes if you wish to remain connected to the same cluster node for each subsequent transaction of an end user. (At least from the standpoint of coming in through an HTTP server). I’m guessing if you do not have session affinity turned on, then you could switch to a different cluster node and it may be trickier to locate your data (especially if you do not replicate it between clusters). It can be done, it just might be a performance hit. So I’m guessing the answer here is “yes”.

    • 0