From World of VOC - Wiki

Jump to: navigation, search

Meet the SessionVOC

Glad to notice your interest in SessionVOC. It will take you only five minutes to learn all about SessionVOC’s essential features and concepts.


In a hurry? You can always install SessionVOC first and give it a try without further background information. Take a look at the quick start section!

SessionVOC is our Open Source solution for session management.

What are SessionVOC’s essential features? It is able to

  • manage session data (even multiple and large sessions)
  • arrange your session data properly
  • answer performance and scaling problems in session/session data areas
  • realize URL signing (protection from session hi-jacking)
  • manage One Time Tokes (i.e., reload protection)
  • simplify the development of multi-page forms


You can find more detailed information about the most important features in the next chapter "essential features".


SimpleVOC not only offers the standard REST interface but even interfaces for many programming languages such as Ruby, PHP, and node.js.

SessionVOC is a memory-based database. It is installed in addition to the relational database. SessionVOC distinguishes between transient and non-transient data. Transient data is “regular” session data that will only be saved until the end of the current session. Non-transient data are user data (personal data) and user settings – the kind of information about a user that is stored permanently.

SessionVOC Architecture

You can configure SessionVOC to fetch non-transient data during session initializing from the database and push it back there (not later than) at the end of the current session. The advantage is that you cut down on queries during the session because user profiles are loaded at one go.

The XML file defines which data will be accessed in the corresponding charts of the relational database. You can create the charts manually or compile them easily using the included Webadmin.

Speaking of XML files: SessionVOC configures even the transient data ex ante in the XML file. Your benefit is the existence of only one single central location that determines which data will be stored in the current session. Larger projects with multiple participants often run to “litter pollution” of the session—nobody knows what kind of information will be stored in the session.

In smaller projects, you can work without XML declaration if you want to. Just create a “blob”-type field once and store all your session data in this blob as in a “general store”.

Essential Features

Performance and Scaling
SessionVOC can process up to 50,000 requests per second. As a memory-based database, it avoids slow-traffic network file systems and redundant synchronizing of the system’s frontends. Master/Master and Master/Slave setups guarantee safeguarding against failure.
URL Signing
URL signing prevents hi-jack attacks and unauthorized access of functions. The URL is augmented by an encrypted signature. SessionVOC manages and verifies signed URLs.
One Time Tokens
One Time Tokes are both nonambiguous and valid for only one request. They are used as reload protection or for transactions.
Form Values
Form Values are a particular SessionVOC data type with a separately definable life time. They are especially useful in multi-page forms to cache form values in SessionVOC until the form’s last page is completed. If the user aborts the process, there will be no litter left in the database because SessionVOC dumps the data at the end of its life time.