Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] NoSQL Session manager 
After a days playing with mongoDB and orientDB, I think I'm
formulating an approach that will work flexibly with most of the
document based nosql implementations.

Firstly, I think I need to go back on my idea posted previously... we
do need our own in memory representation of a session, because it
appears that mongoDB at least does no object caching, so that every
request would end up causing didActive/willPassivate events.

So I think we can work with a session document that looks something like:

 {
    sessionId: "ABCDEFGHIJK12345678890",
    lastAccess: 2011-06-03 12:37:23,
    valid: true,
    attributes: {
      nameA : "value A",
      nameB: binaryBlobOfSerializedObjectB,
      nameC: false
   }
}


The NoSQLSessionManager will then have a number of different policies
that will provide plugable/flexible behavour:


* Staleness Policy *
This control when a request comes in if the manager will trust the in
memory copy and when it will check with the DB if we are holding a
stale copy.  Options are:
  never - assume perfect stickyness, never check with DB (staleness
will still be detected on any writes)
  stale-period - if lastAccess is older than some period, refresh data from DB
  first-request - when number of concurrent request goes from 0 to 1
  every-request
  periodic

* Flush Policy *
This controls when dirty data is written back to the database.  Dirty
data is tracked by noting calls to setAttribute and removeAttribute.
Options are:
  never - we are just an in memory manager.
  every-set . Changes are written as setAttribute is called.
  every-request.  Changes are written when a request completes with
dirty attributes
  last-request. Changes are written when concurrent requests goes from 1 to 0
  periodic.

The flush policy will also have a choice between how writes are flushed:
  save - write the entire session
  set - Set only the dirty attributes (using something like mongoDB $set)

Then there is how write conflicts are handled:
  force - overwrite any changes in the DB
  discard - discard the changes and treat local session as stale
  invalidate - invalidate the session

* Idle Policy *
This controls when the in memory session will be passivated and not
activated.  Options are:
 never - keep sessions in memory until invalidated
 last-request. Idle session when concurrent requests goes from 1 to 0
 idle-period. Idle sessions when idle for a period


* LastAccess Policy *
Controls when the last access field is updated in the DB.  Options are:
 never - in memory only session
 every-request
 last-request
 periodic

Write conflicts for last access are always discarded and used to mark
the session as stale.


* Scavange Policy *
The scavange policy will be three phase:
Phase I - the DB is scanned for timedout sessions.  If found they are
marked as invalid.
Phase II - any session manager loading/refreshing a session that is
found to be stale in the DB will perform the invalidation and call
appropriate listeners.
Phase III -  the DB is scanned for sessions marked invalid that have
double timedout - these are deleted from the DB without loading or
firing any listeners.



thoughts?

Back to the top