Table of Contents
1. Introduction

1.1 Project/Component Working Name
1.2 Name(s) and e-mail address of Document Author(s)/Supplier
1.3. Date of This Document

2.1 Project Description
2.2 Risks and Assumptions

3.1 Problem Area
3.2 Justification

4.1 Details
4.2 Bugs/RFE's
4.3 Scope
4.4 Out-of-scope
4.5 Interfaces
4.6 Documentation Impact
4.7 Configuration/administration Impact
4.8 High Availability Impact
4.9 Internationalization
4.10 Packaging
4.11 Security Impact
4.12 Compatibility
4.12 Dependencies

5. References
6. Schedule

1. Introduction

1.1. Project/Component Working Name

In-Memory Replication for Session Persistence

1.2. Name(s) and e-mail address of Document Author(s)/Supplier

1.3. Date of This Document

08/06/2006

2. Project Summary

2.1. Project Description

In-Memory Replication for Session Replication (HTTP / SFSB)

2.2. Risks and Assumptions

// Note any risks, and assumptions that must be considered along
// with the proposal. Include technical risks.

3. Problem Summary

3.1. Problem Area

// What problem or need does this project solve?
As we move Application Server 9.1EE to Glassfish, we will not
have HADB as a backing store available in Glassfish as open-source. 
For this and other reasons we require a light-weight, low-cost solution
for HTTP Session persistence and Stateful (EJB) Session Bean
persistence.  For Application Server 9.1EE, HADB will still be available
through JES and will continue to provide an HA solution for customers
requiring a persistence solution that provides "5 Nines" availability.

3.2. Justification

Glassfish clustering requires this solution for high-availability and
failover for the web tier and EJB tier.

4. Technical Description

4.1. Details

The general approach is to replicate session state from each
instance in a cluster to a back-up.  Clustered instances will
replicate in a ring topology.  Each backup instance will store
the replicated data in-memory.

No changes will be required for web-tier or iiop load balancers.
Upon a failure the instance now servicing the request (after
failover) will either already have the necessary data or it will
use a broadcast mechanism to obtain and take ownership of
the data.

The plan is to have as close to zero configuration as possible.
Availability configuration will continue to work as it has for
previous HA enabled releases.  There will be a new persistence-type
("replicated").  With this small change, QA and performance tests
should run as they do with HADB.

The technology for inter-process messaging is still under
investigation.

The current plan is to leverage GMS for cluster group membership
services including things like initial bootstrapping/startup and various
cluster shape changes including instances being stopped and re-started,
instances failing, new instances being added to the cluster, etc.

4.2. Bug/RFE Number(s)

// List any Bug(s)/RFE(s) which will be addressed by this proposed change.
// Provide links to the Issue tracker Bug(s)/RFE(s)where possible

4.3. In Scope

4.4. Out of Scope

It is not the aim of this project to provide a generic memory replication
mechanism.

4.5. Interfaces

// Interfaces are a major part of Architectural review.
// Commands, Files, Directory Layout, Ports, DTD/Schema, admin tools,
// config files, APIs, CLIs, and almost anything that is externally
// observable is an interface. In 1-Pager it is necessary to document
// any interface that can be used by external projects and products.
// Documented public interfaces must be assigned a stability level.
// Some commonly used Stability levels in prior projects are:
//
// Stable : Widely used public interface. changed very rarely.
//
// Standard : Defined by a standards body (e.g: JDBCv3). Rare but
// incompatible clarifications and changes could occur
// in a standard. Product will specify version of std
// supported. J2SE, J2EE and WS* are classified
// as Standard.
//
// Evolving : Subject to carefully controlled but possibly
// incompatible change at a major or minor release.
// When a change is made all efforts will be made
// to address incompatiblity and migration. All
// incompatibilities will need to be reviewed
// and approved by as-ccc@sun.com.
//
// Unstable : Early access, subject to unrestricted degree of
// change. A few App Server interfaces are classified
// as Unstable. Docs must call out exported unstable
// interfaces. Be wary of importing Unstable interfaces.
//
// External : Defined external to GlassFish Application Server,
// but not by a Standards body. Suitable for describing
// other freeware, open source interfaces.
//
// http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/
// describes the permitted interface taxonomy.

4.5.1 Exported Interfaces

// Disclose all interfaces that this project exports.

4.5.2 Imported interfaces

// Disclose interfaces this project imports.

4.5.3 Other interfaces (Optional)

// Any private interfaces that may be of interest?

4.6. Doc Impact

// List any Documentation (man pages, manuals, service guides...)
// that will be impacted by this proposal.

4.7. Admin/Config Impact

// How will this change impact the administration of the product?
// Identify changes to GUIs, CLI, agents, plugins...

4.8. HA Impact

// What new requirements does this proposal place on the High
// Availability or Clustering aspects of the component?
There are no new requirements.

4.9. I18N/L10N Impactinks

// Does this proposal impact internationalization or
// localization?
No

4.10. Packaging & Delivery

// What packages, clusters or metaclusters does this proposal
// impact? What is its impact on install/upgrade?
See the packaging and delivery requirements for GMS.
There should be no additional requirments beyond those
already defined there.

4.11. Security Impact

// How does this proposal interact with security-related APIs
// or interfaces? Does it rely on any Java policy or platform
// user/permissions implication? If the feature exposes any
// new ports, Or any similar communication points which may
// have security implications, note these here.

4.12. Compatibility Impact

4.13. Dependencies

// List all dependencies that this proposal has on other
// proposals, components or products. Include interface
// specifics above in the interfaces section;
// LIST dependency component version requirements here.
Technology for inter-process messaging (to be announced)
GMS (see above)

5. Reference Documents

// List of related documents, if any (BugID's, RFP's, papers, Blogs).
// Explain how/where to obtain the documents, and what each
// contains, not just their titles.
GMS One Pager - explains the functionality of Group Membership Service
and its usage of JXTA.

6. Schedule

6.1. Projected Availability

// Dates in appropriate precision (quarters, years)