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