• New Feature
  • Status: Open
  • 2 Major
  • Resolution:
  • DSO:L1
  • prodmgmt
  • Reporter: fhanik
  • January 10, 2007
  • 0
  • Watchers: 1
  • March 19, 2010

Description

In parallel to creating a complete session implementation, I have an idea and would like to start an effort to solve the same problem but using less code. The idea is using a replicated hashmap

Problem: Enable session replication (and context attribute replication) in servlet containers that use HashMap or AbstractMap as the base for session date

Solution: Create an implementation of the hash map that is suitable for storing sessions in

Here are some details:

  1. implement the map using the TC API instead of byte code manipulation
  2. map.put() triggers “root” object behavior.(replicates data to L2)
  3. map.get will retrieve the object directly from memory or L2
  4. map.keySet and map.entrySet only returns data that is loaded into the current heap
  5. map.remove removes locally and on L2 (and on other maps if needed)
  6. map.clear - only removes objects stored in heap from L2

Locking would be done using a valve and would also solve the cross context invokation problem No manipulation of the session id as this would also support JVM route rewriting

Problems not solved: Locking for async servlets

I’ll fill in more info as needed.

Comments

Eugene Kuleshov 2007-01-15

By the way, please note that in case if some node die, its local keyset should be picked up by some other node.

It is also unclear/tricky, how remove will be propagated. Say, some node called remove on instance that is not in its local collection. So, it will go to L2, but how it will get to local collection on node that own that instance?

I can only think of creating collections/maps per node. So nodes would have “local” map/keyset that is inside shared map (and that inner map can be write-locked eagerly by its owner). Then, if one of the nodes die, its map can be copied into some other node map (i.e. triggered by newly introduced cluster events, or by some monitoring thread).

Another issue to think about, is how put will be propagated if aggregated map already has value for that key.

Fiona OShea 2007-02-07

Updating Due date to last day of Moraga dev iteration