המחזה מתחיל לאחר התאבדות ביאטה, אשתו של רוסמר. רבקה עברה לפני כן להתגורר בבית המשפחה, רוסמרהולם, כחברה של ביאטה, והיא עדיין מתגוררת שם. ניתן להבין שהיא ורוסמר מאוהבים, אולם הוא מתעקש לאורך כל המחזה לטעון שהיחסים ביניהם הם אפלטוניים לחלוטין.
רוסמר, חבר מכובד מאוד בקהילתו, מתכוון לתמוך בממשלה שנבחרה זה עתה ובאג'נדה הרפורמיסטית, אם לא המהפכנית שלה. אולם, כאשר הוא מצהיר על כך בפני חברו וגיסו קרול, מנהל בית הספר המקומי, קרול זועם על מה שהוא רואה כבגידתו של חברו בשורשי המעמד השליט. קרול מתחיל לחבל בתוכניותיו של רוסמר, מעמת אותו עם יחסיו עם רבקה ומוקיע את הזוג בעיתון המקומי. רוסמר מתחיל להיתקף ברגשי אשמה, בהאמינו כעת שהתאבדותה של אשתו נגרמה בשל מעשיו ולא בשל מחלת הנפש שלקתה בה. הוא מנסה להימלט מתחושת האשמה במחיקת זיכרון אשתו על ידי כך שהוא מציע נישואים לרבקה. אך היא דוחה אותו מייד. קרול מאשים אותה בכך שהיא השתמשה ברוסמר ככלי לקידום האג'נדה הפוליטית שלה. היא מודה בכך שהיא דחפה את גברת רוסמר למעמקי יאוש עמוקים ובמובן מסוים בכך שעודדה את התאבדותה. – בתחילה כדי שתהיה לה עמדת כוח על רוסמר, אולם אחר-כך מכיוון שהיא התאהבה בו. בשל אשמת העבר שמכרסמת בה, היא אינה יכולה להיענות להצעת הנישואים של רוסמר.
הדבר מוביל לבסוף לקריסה במחזה בו לא רוסמר ולא רבקה אינם יכולים להיפטר מרגשות האשמה שלהם. היא מודה בחלקה בהריסתה של ביאטה, אולם היא גם חטאה בגילוי עריות עם מי שהוא לכאורה אביה המאמץ כשחשדה בכך שהוא למעשה היה ההורה הביולוגי שלה. חשדותיה מקבלים ביסוס בידי קרול כשהוא מנסה לסכסך בינה לבין רוסמר; כעת הם אינם יכולים עוד לבטוח זה בזו, או אפילו בעצמם. בנקודה זו רוסמר מבקש מרבקה להוכיח את מסירותה לו בבצעה התאבדות באותה הדרך שעשתה אשתו לשעבר – בכך שהיא תקפוץ לתוך הסכר. כשנדמה שרבקה נענית לכך, נותנת הנחיות למשיית גופתה מהמים, רוסמר אומר שהוא יצטרף אליה. הוא עדיין מאוהב בה, ומאחר שהוא אינו רואה אפשרות שהם יוכלו לשוב ולחיות יחדיו; הם ישימו קץ לחייהם ביחד. המחזה מסתיים כששניהם קופצים לסכר ומנהלת משק הבית, גברת הלסט, צורחת באימה: "
דמויות משנה.
פעולותיהם של ברנדל ומורטנסגור אינן מניעות קדימה את העלילה, אם כי מורטנסגור חושף בפני רוסמר שביאטה שולחת לעיתון שלו מכתב המכחיש את השמועות לכך שבעלה בוגד בה עם רבקה: המחשבה על כך שאשתו אפילו התייחסה להאשמה חסרת בסיס זו, מה שהוביל אותה להחלטתה לשים קץ לחייה, מצערת את רוסמר מאוד.
בפעם הראשונה כעבור שנים רבות, ברנדל מגיע לרוסמרהולם כשבכוונתו להטיף לחופש פוליטי ורפורמות בעירו. הוא מגיע לבית מרזח אפל, משתכר, נאם וכינה את החברה "אספסוף", והשליכו אותו החוצה לביוב. הוא שב לרוסמרהולם אחרי התקרית, ומודיע על גוויעת האידיאלים שלו בעקבות הקורות אותו. כעת הוא ממליץ על גישתו של מורטנסגור הפרגמטי, שמאיץ ברוסמר לתמוך בתנועת הרפורמה בעודו עדיין נוצרי, חרף העובדה שרוסמר איבד את אמונתו. מורטנסגור זקוק לתמיכתו הפומבית של רוסמר כדי להראות שישנם אזרחים חשובים, מכובדים ודתיים שמסכימים עם האידאולוגיה שלו.
דימויים.
הדימוי העיקרי במחזה הוא הסוס הלבן של רוסמרהולם, או כפי שרבקה קוראת "רוחות רפאים". רווחות שמועות על כך שהנפשות הפועלות ראו אותו לאחר התאבדותה של ביאטה. הסוס מסמל את העבר שסובב סביב אשתו המנוחה של רוסמר, ורודף את קרוביה שנותרו בחיים. נוכחותו של הסוס במותם מייצג את חוסר היכולת להתמודד עם הזיכרונות שפוקדים אותם. הסוס הלבן דומה ל"רוחות" אליהן מתייחסת גברת אלווינג בטרגדיה "רוחות" של איבסן משנת 1881.
איבסן בחר בשם רוסמר עבור הפרוטגוניסט שלו כהד מודע לאגדה הנורווגית על "רוסמר הבמנד", שד ים שמפתה נשים צעירות למות בטביעה; הוא מפתה
את רבקה לפתחו של אסון.
שמו המקורי של המחזה היה אמור להיות "סוס לבן", כדי להבליט את חשיבות המרכיב העל-טבעי במחזה.
רוסמרהולם בתיאטרון הרפרטוארי הישראלי.
תיאטרון חיפה, הצגת בכורה: 21 בספטמבר 1989, מספר הצגות: 20
Session
במדעי המחשב ובייחוד בתקשורת נתונים, session (סשן), ובעברית שיח, היא החלפת מידע אינטראקטיבית חצי-קבועה, הידועה גם כ"שיחה", "התקשרות", "דיאלוג" או "פגישה", בין שני מכשירים מתקשרים או יותר, או בין מחשב למשתמש קצה. סשן מוקם או מבוסס (established) בנקודה מסוימת בזמן, ונהרס בנקודה מאוחרת יותר. סשן תקשורת מבוסס יכול לכלול יותר ממסר אחד בכל כיוון. בדרך כלל, אבל לא תמיד, סשן הוא stateful, כלומר, לפחות אחד מהצדדים המתקשרים צריך לשמור מידע אודות ההיסטוריה של השיחה על מנת שיוכל לתקשר, וזאת בניגוד לתקשורת stateless, המורכבת מבקשות ותגובות נפרדות.
סשן תקשורת (communication session) ניתן למימוש כחלק מפרוטוקולים ושירותים בשכבת היישום, בשכבת השיחה או בשכבת התעבורה של מודל ה-OSI.
דוגמאות לסשנים בפרוטוקולי תקשורת שונים:
במקרה של פרוטוקולי תעבורה שאינם מממשים שכבת סשן פורמלית (לדוגמה: UDP), או במקרים בהם זמן החיים של סשנים בשכבת השיחה הוא בדרך כלל קצר ביותר (לדוגמה: HTTP), סשנים מנוהלים על ידי תוכנה שהיא high-level יותר, באמצעות שיטות המוגדרות בנתונים המועברים עצמם. לדוגמה, העברת נתונים בפרוטוקול HTTP בין דפדפן לשרת מרוחק יכולה לכלול עוגייה (cookie) המשמשת לזיהוי מצב, כגון מזהה סשן (session ID), מידע אודות העדפות המשתמש או רמת הרשאות.
מימושי תוכנה.
סשנים בפרוטוקול TCP בדרך כלל ממומשים ברמת התוכנה, באמצעות יצירת תהליכים בנים (child processes) או על ידי שימוש בריבוי תהליכונים (multithreading). במקרה זה, עבור כל סשן חדש שנוצר נפתח תהליך או תהליכון חדש. סשנים בפרוטוקול HTTP בדרך כלל לא ממומשים על ידי שימוש בתהליכון עבור כל סשן, אלא על ידי שימוש בבסיס נתונים אשר שומר מידע אודות המצב של כל סשן. היתרון בשימוש בריבוי תהליכים או תהליכונים הוא בכך שהלוגיקה של התוכנה יכולה להיות פשוטה יחסית, מכיוון שכל תהליכון הוא ישות בעלת היסטוריה משלה ועם משתנים משלה שהיא מכמסת. החיסרון הוא בתקורת משאבים גבוהה, ובכך שהסשן יכול לאבד במקרה של הפעלה מחדש של המערכת (ראו: persistence).
במקרים בהם הלקוח עשוי להתחבר לכל אחד מהשרתים באשכול (cluster) של שרתים, נוצרת בעיה מיוחדת בשימור ההמשכיות כאשר השרתים חייבים לשמור מידע אודות מצב הסשן. במקרה כזה חייבים להכווין את הלקוח לאותו השרת למשך כל זמן הקיום של הסשן, או שהשרתים חייבים להעביר את נתוני הסשנים בצד השרת באמצעות מערכת קבצים משותפת או בסיס נתונים משותף. אחרת הלקוח עשוי להתחבר מחדש לשרת שונה מזה שהתחיל איתו את הסשן, מה שיגרום לבעיות כאשר לשרת החדש אין גישה אל נתוני הסשן שנשמרו בשרת הקודם.
HTTP Sessions.
תחילה היה נחשב שגרסה 1.1 של פרוטוקול ה-HTTP מאפשרת רק בקשה ותגובה (request and response) אחת במהלך סשן HTTP יחיד. עם זאת, בשנת 1996 דייוויד הוסטטלר ויין יצר פתרון שעקף מגבלה זו, כך שניתן יהיה להשתמש ב-session IDs על מנת לאפשר עיבוד רב-שלבי של טרנזקציות רשת (multiple phase web transaction processing). הגרסה הראשונה של מערכת לניהול סשנים נקראה Deity ("אלוהות"). גרסה 1.1 של פרוטוקול ה-HTTP שופרה עוד יותר על ידי השלמת ה-(Common Gateway Interface (CGI ובכך אפשרה שימור קל יותר של סשן רשת ותמיכה בעוגיות והעלאת קבצים.
רוב הסשנים שנפתחים בין שרת ללקוח מנוהלים בשכבת התעבורה – עבור כל סשן נפתח חיבור אחד. עם זאת, כל שלב (phase) בסשן של טרנזקציית רשת בפרוטוקול HTTP יוצר חיבור נפרד (חיבור נפרד עבור כל זוג של בקשה-תגובה). שימור ההמשכיות בין שלבים דורש שימוש במזהה סשן (session ID). המזהה מוטבע בתוך האלמנטים codice_1 ו-codice_2 של שפת ה-HTML בדפי אינטרנט דינמיים, כך שהוא מועבר חזרה אל ה-CGI בצד השרת. לאחר מכן ה-CGI משתמש ב-session ID על מנת להבטיח את המשכיות הסשן בין שלבי הטרנזקציה. אחד היתרונות של חיבור נפרד עבור כל שלב הוא בכך שזה עובד טוב על פני חיבורים עם רוחב פס נמוך.
סשנים של צד לקוח בפרוטוקול HTTP.
סשנים של צד לקוח בפרוטוקול HTTP משתמשים בעוגיות (cookies) ובטכניקות הצפנה על מנת לשמור מידע אודות המצב (state), מבלי שיהיה צורך לשמור כמויות גדולות של נתונים בצד השרת. כאשר השרת מציג דף אינטרנט דינמי, הוא שולח ללקוח (הדפדפן) נתונים אודות המצב הנוכחי בצורה של עוגייה. הלקוח שומר את העוגיה בזיכרון או על הדיסק. בכל בקשה (request) עוקבת שהלקוח שולח חזרה אל השרת, הוא מצרף את העוגייה, והשרת משתמש בנתונים שבעוגייה כדי "לזכור" את המצב של היישום עבור אותו לקוח ספציפי, וכדי ליצור תגובה (response) מתאימה.
מכניזם זה עובד טוב ברוב המקרים. עם זאת, נתונים אשר מאוחסנים בצד הלקוח חשופים לשינויים זדוניים על ידי הלקוח או על ידי תוכנה שיש לה גישה למחשב הלקוח. על מנת להשתמש בסשנים בצד הלקוח במקרים בהם נדרשת סודיות ואמינות, יש להבטיח את הבאים (CIA):
על מנת להשיג אבטחת מידע כזאת, ראשית על הלקוח לאמת את זהותו של השרת (נעשה לרוב על ידי הצגת Public key certificate מצד השרת), לאחר מכן על השרת להצפין את נתוני הסשן לפני שליחתם אל הלקוח, ויש למנוע את השינוי של מידע זה על ידי כל גורם אחר חוץ מהשרת, גם כן באמצעות שימוש בשיטות הצפנה.