Session handling in OXID eShop 6

With OXID eShop 6, there will be some changes in the session storage system. Until now there was the regular PHP session handling using the file system. Optionally, with the config option blAdodbSessionHandler, a feature of ADOdb lite was used to store sessions directly to the OXID database.

As we replaced ADOdb lite with the more modern Doctrine DBAL database layer, this feature will not be available any longer. There are clever alternatives that will make your OXID eShop project even more scalable, better performing and getting better fail-over capabilities.

When working on regular web space, a vServer or even a root server, nothing will change for you. This blog post is interesting for you if you’re running multiple application servers or hosting in the scalable cloud.

Sticky Sessions

By default, PHP handles sessions on basis of the file system. This works perfectly as long as you run a small or medium sized online business with one server or a hosting package. Although this solution is very easy to implement, there are some disadvantages when it comes to multiple application servers with an upstream load balancer:

A load balancer assigns the first client request to a physical application server (see figure below), and all following requests of this client to the same physical server. In order to remember the client, the load balancer tries to identify it via:

  • it’s IP address
  • TCP payload offset and length
  • HTTP query string elements
  • header field values
  • cookies
  • etc.


As mentioned above, using sticky sessions, sessions are saved locally in the file system of the application server. This may provoke problems if a client with an active session is assigned to another application server because his session data is suddenly lost. This may occur for example if

  • the application server has to much load and the load balancer can’t assign more clients to this application server
  • during the maintenance time of an application server
  • a user is not identified correctly because it’s IP changes, NAT networking, etc.

Non-sticky sessions

In order to resolve these issues, there’s another concept known as “non sticky sessions”. In this scenario, the load balancer may assign any of the physical application servers to serve a request. The session data is saved centrally:


Until now we supported the non-sticky session concept by writing the sessions into the OXID database via ADOdb lite using the OXID eShop option blAdodbSessionHandler. Unfortunately, using the application server database as session storage, has some disadvantages as well:

  • the more application servers used, the less scalable it is to use the application server database.
  • the application database server gets even more load by the sessions. Sessions ususally have a read/write ration of 1/1.
  • the application database can become very large.

Use your own session storage

ADOdb lite was replaced with Doctrine from OXID eShop 6 on, so the feature of writing sessions by simply switching on an option is not available any longer.

Also, there are manifold other solutions out there for session handling like Memcached Session Manager or Redis. The setup is simple as there are already PHP plugins available (php5-redis) – you just have to tell your PHP installation to use Redis as a session handler. Please read this blop post for more information:

If you want to store your sessions into a database anyway, you have the possibility to write your own session handler. Here are some hints on how to do that. First, you have to implement a class which has access to your session storage and implements some standard methods like read and write (like the old adodb class core/adodblite/session/adodb-session.php).

class MySessionStorage
    public function init()
            array('MySessionStorage', 'open'),
            array('MySessionStorage', 'close'),
            array('MySessionStorage', 'read'),
            array('MySessionStorage', 'write'),
            array('MySessionStorage', 'destroy'),
            array('MySessionStorage', 'garbageCollection')

    public function read()
    public function write();
    public function destroy();
    public function update($newSessionId, $oldSessionId);
    public function open();
    public function close();
    public function garbageCollection();
    protected function write_close();

In order to make this class work with OXID eShop, you have to extend the OXID eShop Session class with a module.

 * extends OxidEsales\Eshop\Core\Session
class MySession extends MySession_parent

    protected function _sessionStart()
        $started = parent::_sessionStart();

        return $started;

    protected function initializeMySessionStorage()
        $mySessionStorage = oxNew('MySession');
    protected function _getNewSessionId()
        $oldSessionId = session_id();
        $newSessionId = parent::_getNewSessionId();
        $this->mySessionStorage→update($newSessionId, $oldSessionId);
        return $newSessionId;

    protected function _isSwappedClient()
        $swapped = parent::_isSwappedClient();
        if (!$swapped) {
            // return true if the new session id is already present in the storage (used by a swapped user)

        return $swapped;

If you have questions, please don’t hesitate to comment this blog post.

4 replies
  1. oxondra
    oxondra says:

    Thanks for your reply. In that case, I would prefer extending core Session class that should also provide a full modularity, or is there any other reason for aliasing core classes?


Trackbacks & Pingbacks

  1. […] The possibility to save Sessions to the eShop application database was removed. This was a feature of ADOdb Lite which was replaced by Doctrine DBAL. A blog post about session handling and storage in OXID eShop V6.0 and can be found on oxidforge. […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *