• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Interview Question - How to persist session across Weblogic?

 
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So I just got off the phone from an interview. I am pretty sure I failed it. The man interviewing me kept asking me about session persistence. I wasn't quite sure what he was asking. His exact wording was "How do you persist session across Weblogic?".

My answer was what seemed obvious. Using the session object. When a browser connects to a server a session object is created for that connection and anytime you need to get/set an attribute from this session object get it from the request object and use the get/setAttribute methods to update the object.

He didn't seem satisfied with this answer. He said "There are 4 or 5 ways to persist session. How do you do it?" So I told him the following reasons:

- The session object is automatically persisted on the server for the life of the browser being open or until it is invalidated through the invalidate method.
- You can persist using URL rewriting.
- You can persist by writing cookies to the user's browser.
- Lastly...I said I thought there was a "Sticky Session" attribute in the config files you could use but I wasn't 100 percent sure.

At that point he seemed to give up on the interview. What did I miss? Are there four ways to persist session that every J2EE developer knows that I just don't know about? What answer was he looking for?!?!?!?
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi,

Your answer is right, but maybe the question is not. The man should have asked: How does Weblogic implements session persistence?

Weblogic has several ways to implement session persistence (to be more accurate: session [B]replication[B]) depending on your architecture:

If you have a single server, session is persisted "in memory", but if you have a cluster, session must be replicated to all servers.

Weblogic offer basically 2 ways for session replication: using the network (by sending multicast messages to groups of servers) or using a database to persist the serialized session objects.

Which one is better? That depend on several factors (the number of servers in the cluster, the load balancing method you use, etc.)

If you are interested on details or other aproaches, check Bea's doc.
[ June 07, 2005: Message edited by: Pedro Gongora ]
 
James Ellis
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Pedro. I agree with what you said. I think what he was trying to ask was "How does Weblogic implement session persistence across multiple servers". If he had asked that...I might have been able to give him a better answer.
 
Greenhorn
Posts: 2
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I know this thread is extremely old, but while I was looking for something different I ran across this and saw that it was never truly answered properly. In case anybody else runs across it I felt it should at least convey the correct information for whoever runs across it. I have also always wanted to join JavaRanch and never got around to it, so this was as good an excuse as any.

When the interviewer asked this question, he was referring specifically to the different forms of session persistence that WebLogic offers. You answered this question partially, but did not truly provide the typical answer that an interviewer asking this question is expecting. This was more of a WebLogic than a Java EE question, and you provided the Java EE response.

Back in 2004 when this thread was written, the main forms of session persistence, also commonly referred to as session replication but is only replicated in a few of the scenarios, included:

  • No persistence: If your server crashes, all sessions are lost.

  • In-memory session replication: Session state exists on two servers in a cluster. One is the primary that the LB will always call, while updates are replicated to a backup copy on another server (preferably on another machine). If the primary server crashes, the backup is tapped to re-establish a new primary/backup combination and the session data is preserved.

  • File-based persistence: No replication takes place. Session data is written to a file. All servers in the cluster must have access to the file system where sessions are persisted; otherwise, failover cannot work. If a server crashes, the LB failsover to another server and that server accesses the session data from the shared disk.

  • JDBC-based persistence: No replication takes place. Session data is written to a database. This scenario is the same as file-based, except all servers must have access to the same database.


After Oracle acquired BEA in 2008, they also began a push toward tighter integration of Coherence with WebLogic and the Coherence*Web session persistence mechanism became a more well-known concept as well. This is where the HTTP Session persistence mechanism within WebLogic is overridden to store HTTP Sessions on a Coherence distributed cache instead of using WebLogic's built-in mechanisms. Behind the scenes, Coherence stores the data in a primay/backup method as well. It is different than how WebLogic does it, but the basic concept of keeping and managing a backup for failure recovery is the same. Now in 2013, Coherence*Web integration is tighter and configuration is done the same as other "built-in" WebLogic session persistence methods using the session-descriptor element of the weblogic.xml file.

You most likely have picked up this knowledge yourself a long time ago James... I was just looking to finish the topic off for others
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks your late reply was helpful to me.
 
Mark Lindros
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Pedro Gongora wrote:hi,

Weblogic offer basically 2 ways for session replication: using the network (by sending multicast messages to groups of servers) or using a database to persist the serialized session objects.

[ June 07, 2005: Message edited by: Pedro Gongora ]



Again, this is old but I want to make sure whatever is read in here is accurate.

The statement above is partially true, regarding the fact that WebLogic cluster members do communicate to each other using multicast (but not for replication of HTTP Sessions) and sessions that are stored in the database are serialized. This is an area where people who are learning / becoming familiar with WebLogic get confused.

WebLogic uses multicast (and after this original writing it also uses unicast TCP) communication for sending heartbeat messages to all other cluster members, and for synching the global JNDI tree across all cluster members. Session replication is done using peer to peer TCP socket connections from a primary cluster member to a secondary cluster member.

For the record, I was with BEA as both a WebLogic consultant and was the worldwide staff engineer responsible for developing and delivering new training on every WebLogic Server release from 5.1 to 10.0 to the internal BEA field so they would be prepared for supporting our customers. I was acquired with the BEA acquisition by Oracle and have been an Oracle Consulting Technical Manager working on WebLogic projects, and I am now a Curriculum Developer for WebLogic and other products at Oracle.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic