Re: Mainitaining Session in Application Server

Have you ever thought about abstracting the cluster behavior from your
application and leaving that part of the solution up to the hardware ---
the load balancer itself.

I'm assuming you have a setup where there's a proxy in front of a load
balancer in front of the cluster of app servers.  By using a load balancer
with Layer 4 [for IP balancing with your Java stand alone app clients] AND
Layer 7 [for balancing with cookies with your web clients ] you could now
employ the singleton solution b/c you'll be guaranteed that each session
will at least hit the same app server each time.  This keeps the app
simpler and more re-usable across a multitude of app servers.  If you went
the JNDI solution, you'd be tied to one app server [WebLogic].

If this isn't the best solution, seperate the problems to find
mini-solutions that are still flexible with your whole architecture.

At 08:52 AM 12/10/2003 -0500, Zerbe John W wrote:
>It looks to me like you have conflicting requirements.
>You want one instance of some object that tracks session state for
>all users of your app, you do now want to use a database for this,
>and you want it to work in a cluster of application server instances.
>
> From what you have described of your requirements, I believe that a
>relational database, keyed on a userid is your best bet. Whether you
>implement via entity ejbs or via direct sql from a SLSB is your
>choice.
>
>All members of the cluster have access to it. The database itself can
>provide mutual exclusion on individual entries. You don't have to have all
>the entries in memory at the same time in all the members of the cluster.
>If you are using a database connection pool, retrieving the individual
>entries
>is really no more expensive than any other operation that requires a network
>hop. Most databases are really quite good at caching the most used "rows" in
>memory. Typically, databases are put on machines that are set up for some
>sort of "failover" or some sort of clustering that make them very reliable.
>If you try for some sort of "cluster wide singleton", you will end up with
>your info resident in a single member of your cluster and therefore have
>a single point of failure in your application.
>
>At least WebSphere uses a relational database for http session persistence
>in a clustered environment. I don't know if this is available in other
>vender app servers. In our environment, we can lose a whole application server
>machine and not lose session state for our apps. We also don't have the memory
>footprint that would be required for all app server instances to have all
>current
>session object in memory like an app server to app server replication
>solution
>would require.
>
>
>John Zerbe
>
>-----Original Message-----
>From: A mailing list for Enterprise JavaBeans development
>[mailto:[email protected]]On Behalf Of Saidas Kottawar
>Sent: Wednesday, December 10, 2003 12:22 AM
>To: [email protected]
>Subject: Re: Mainitaining Session in Application Server
>
>
>Hello All,
>
>First of all Thanks for your responses.
>I would also like to say sorry since it looks like the question was not
>very clear from my side. Most of the people has answered very lightly
>with one line.BTW, I am not a newcomer to this technology and working
>from more 3 years. So my question has a really a trivial one.
>BTW, I have got so many responses from so many people and I replied
>personally to most of them..since they have answered personally.
>Here I am giving brief summary of them (I have drawn some time from
>tight schedule...i should...so that we can help each other).
>Here we go one more time :
>
>What I want (this time it looks more improved from my side :)?
>-->
>We have created only server side application in our product i.e. we have
>created only EJBs.
>The client is going to interact with this server side application
>through proxy. Proxy will interanally make a JNDI call to proper server
>side objects. We provide API(proxy) for communicationg with server side
>components.
>
>CLIENTS:  Client can be a web based i.e. browswer or it can be
>standalone Java application...in broad sense client can be any one. We
>don't have to worry since it is always using proxy API.
>
>What is the problem?
>We want to keep track of all the users logged in the system...keeping
>track on server side.
>So we want something(some object) which can be accessed by any EJBs in
>any cluster. It is same like ServletContext object in Servlet. We want
>some object which is available on application level.
>
>What we want to achieve?
>We want to keep track of all the users logged in. So whenever the user
>logs in, we will make this entry in Application wise object. So for each
>new request, we will check, by using this object, whether user has
>logged in or not. So basically we want to keep all users in one
>place..we want to keep session ID of all the users in one place.
>
>There should be only one instance of this object across the application.
>It should work in cluster enviornment.
>
>What suggestion I got and my view on the same?
>1. Use Statefuls session bean --> Can't serve my purpose. StatefulSB is
>reserved by a client and it is not Application level.
>
>2. Use Singletone object --> Will not going to work in cluster
>enviornment.
>
>3. Use JNDI object (This solution looks feasible for me :) Thanks to
>Ashu for the same.)
>         1. Create your own object with the data that you want to share
>across the users.
>         2. Register this object in the JNDI tree of the application
>server.
>         3. By registering the object, your data will be available across
>the cluster.
>         4. Lookup for the object whenever you application needs the
>data.
>         5. Just think of the object as one whose reference is shared
>across the application server. You will need to make it
>thread-safe.
>
>Waiting for all REPLIES.
>
>Thanks and Regards,
>Saidas Kottawar
>
>===========================================================================
>To unsubscribe, send email to [email protected] and include in the body
>of the message "signoff EJB-INTEREST".  For general help, send email to
>[email protected] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[email protected] and include in the body of the message "help".