Makes any storage strategy similar to
express/session useful in both
cluster and non-
by wrapping it with
Also works with level-session-store (leveldb), connect-session-knex (SQLite3), session-file-store (fs), and any other embedded / in-process store.
Note: Most people would probably prefer to just use Redis rather than wrap a dumb memstore as a service... but I am not most people.
npm install --save firstname.lastname@example.org
v1.x vs v2.x
The old v1
ws which makes it usable when clustering node processes without using
If you need that functionaliy, use v1 instead of v2.
In its simplest form, you use this module nearly exactly the way you would the any other storage module, with the exception that you must wait for the inter-process initialization to complete.
When not using any of the options the usage is the same for the master and the worker:
There is no disadvantage to using this module standalone. The additional overhead of inter-process communication is only added when a worker is added.
As such, the standalone usage is identical to usage in master process, as seen below.
In the master process you will create the real store instance.
If you need to manually specify which worker will be enabled for this funcitonality
you must set
false and call
'use strict';var cluster = ;var cstore =;// if you addOnFork is set to false you can add specific forks manually//cstore.addWorker(cluster.fork());cstore;
store can be replaced with any
express/session-compatible store, such as:
- and others
'use strict';// retrieve the instancevar cstore =;cstore;
This is modeled after Express' Session Store Implementation
Note: These are only exposed if the underlying store supports them.
store.set(id, data, fn) => (error)
store.get(id, fn) => (error, data)
store.touch(id, data, fn) => (error)
store.destroy(id, fn) => (error)
store.all(fn) => (error, array)
store.clear(fn) => (error)
store.length(fn) => (error, length)
See https://email@example.com for full details
'use strict';var cluster = ;;if clusterisMastercluster;cluster;