In a previous post I described some of the reasons why you would want to store your session data in an alternate location to temporary files on your server. I explained the setup of database session storage using Doctrine and how this would allow you to take advantage of storing session data in a database. However depending upon your application requirements storing your session data in a database may cause excessive load on you database. You could of course use a separate dedicated database server to store your session data. However there is an alternate setup that will allow you to centralise your session storage ready for horizontal scaling of your hosting e.g. adding additional web servers.

symfony provides a very easy way for you to configure your application to use a number of alternate session storage strategies. In this article I will explain the steps needed to setup your application to use first APC as your session storage and then Memcache. Both of these strategies result in the session data being stored in volatile memory on your server and a cookie is stored on the client to maintain reference to the session data. You can set the lifetime of the cookie to control your session timeout.

Install APC and Memcached modules

First we need to ensure that your server has the required packages installed. I am using Ubuntu 9.04 in this example but the packages are available for your preferred linux distro. To install the required packages run the following commands.

Install the required PHP modules and the correct version of apache to successfully install APC, then install the Pecl APC module.

sudo apt-get install php5-dev php-pear apache2-threaded-dev
sudo pecl install apc

Install memcache

sudo apt-get install memcached

Configure APC session storage

Once you have your server setup with the required packages you need to configure symfony to use your preferred session storage strategy. To do this you simply need to modify the factories.yml file for you application. You need to modify the section of the factories.yml that defines your application storage strategy e.g.

Amend your factories.yml to include the following settings then change the parameters to reflect you setup such as the domain and session name.

all:
  storage:
    class: sfCacheSessionStorage
    param:
      session_name: sfproject #[required] name of session to use
      session_cookie_path: / #[required] cookie path
      session_cookie_domain: example.com #[required] cookie domain
      session_cookie_lifetime: +30 days #[required] liftime of cookie
      session_cookie_secure: false #[required] send only if secure connection
      session_cookie_http_only: true #[required] accessible only via http protocol
      cache: 
        class: sfAPCCache #[required] define the cache strategy
        param: ~ #[required] this empty key is required or you will get warnings

Once you have made this change clear the symfony cache and try your application. You will not see any noticeable difference unless you check the symfony toolbar and look for the additional cookie stored on the client.

This example defines the use of sfAPCCache as the session storage strategy. APC stores the session data in memory on your web server making it quicker to access than reading a file or database record.

Configure Memcache session storage

To setup memcache session storage it is almost as simple. Amend your factories.yml to include the following settings then change the parameters to reflect your setup including any specific values for your memcache server if you set it up differently.

all:
  storage:
    class: sfCacheSessionStorage
    param:
      session_name: sfproject #[required] name of session to use
      session_cookie_path: / #[required] cookie path
      session_cookie_domain: example.com #[required] cookie domain
      session_cookie_lifetime: +30 days #[required] liftime of cookie
      session_cookie_secure: false #[required] send only if secure connection
      session_cookie_http_only: true #[required] accessible only via http protocol
      cache: 
        class: sfMemcacheCache #[required] define the cache strategy
        param:
          servers: # Array of servers
            localserver:
              host: localhost # hostname or IP of mamcache server
              port: 11211 # default memcache port

Once you have made this change clear your symfony cache and test your application.

Memcache is a volatile storage strategy very similar to RAM in you PC or Mac. It is very quick to access as the session data is held in the server memory rather than in a file or database. Memcache can also be centralised onto a dedicated memcache server allowing your application to be scaled. The example above uses localhost as the memcache server but the host value of the configured server could be modified to be an alternate dedicated memcache server.

I will be running some performance tests using these strategies and also compare the default file based session storage and also the database session storage strategy. If you have already run these tests I would be keen to see your results.

I hope these examples prove useful. If you have any queries or questions please leave a comment.

Related Articles

• November 25, 2009 -- symfony Doctrine database session storage
• October 8, 2009 -- Propel doUpdate update multiple records in a single statement

Why use database session management?

Sessions allow you maintain persistence within PHP applications. With every HTTP request a PHP application must re-assign every variable and object needed in your application. Sessions allow you to store data that is required to persist past each HTTP request allowing it to be easily retrieved and used.

Sessions are commonly used when  creating a secure application, used to store the state of a user e.g. if they are logged in or credentials to control access to content.

By storing session data in a database table you are able to create an application interface that will show information about the users that are logged in. This for example could show the number of users logged into the application or show administrators who is logged in.

If you  need to scale your application by adding more than one server, saving your session data in temporary files can lead to major problems. By using database storage you can optimise and unify the session storage, ensuring that session data is always available and consistent.

Obviously there are other solutions for scalable session storage such as APC or MemCache but these solutions are for another post.

How to setup Doctrine database session storage

You first need to add a table to you database schema that will be used to store your session data. Although you can create this table manually, adding it to your scheme also created the model classes that you can later use to interact with the table data.

Session:
  columns:
    id: { type: string(32), primary: true, notnull: true }
    data: { type: string(4000), notnull: true }
    time: { type: integer(4), notnull: true }

Once you have added the table to your schema you can build your model and database:

./symfony doctrine:build-all

You then need to configure your symfony application to use this table to store all session data. To do this you need to modify the factories.yml file for your application. Update your file to include the following lines:

all:
  storage:
    class: sfPDOSessionStorage
    param:
      db_table: session # Name of the table storing the sessions
      db_id_col: id # The primary key column
      db_data_col: data # The column where the session data will be stored
      db_time_col: time # The column where the timestamp of the session will be stored
      database: doctrine # Name of the database connection to use

Once you have modifies your factories.yml file you will need to clear the symfony cache. After that your application should run exactly as it did before except that your users session data will be stored in the database table.

The data column stores all the session data in a serialised form this is deserialized each time a user requests the data. There are many uses for this type of session storage and I hope this brief explanation helps you.

Subscribe to my RSS feed or follow me on twitter to find out about setting up symfony to use APC or MemCache session storage.

Related Articles

• November 30, 2009 -- symfony APC cache and Memcache session storage
• October 8, 2009 -- Propel doUpdate update multiple records in a single statement

This task is simple in SQL but after a while using any abstraction layer you may find like me you forget about the simple solutions as you spend you day working with complex objects and trying to hydrate custom objects. Blah blah blah…

The complex solution to a simple problem:

// Obtain the connection configured
$conn = Propel::getConnection(YourObjectPeer::DATABASE_NAME);
// Create a Criteria object that will select the correct rows from the database
$selectCriteria = new Criteria();
$selectCriteria->add(YourObjectPeer::COLUMB_TO_SELECT, 'value_to_match');
// Create a Criteria object includes the value you want to set
$updateCriteria = new Criteria();
$updateCriteria->add(YourObjectPeer::COLUMB_TO_CHANGE, 'value_to_be_set');
// Execute the query
BasePeer::doUpdate($selectCriteria, $updateCriteria, $conn);

Thats it! I hope it helps…

Related Articles

• November 30, 2009 -- symfony APC cache and Memcache session storage
• November 25, 2009 -- symfony Doctrine database session storage

This plugin was built after reading “Designing the Obvious” by Robert Hoekman, jr. and working with a number of unsatisfactory validation libraries. It is intended that this plugin will allow you to configure the validation and feedback to make your forms poka yoke devices i.e. impossible for users to make any errors while entering data.

Thanks to Alon Noy for a starting point for the validators! The following symfony validators have been ported to JavaScript implemented in the plugin:

• sfStringValidator
• sfNumberValidator
• sfRegexValidator
• sfEmailValidator
• sfCompareValidator

I also plan to implement a client side callback validator that will allow you to call your own client side validators or even call ajax function to run server side validation in real time.

Installation

To install the plugin you can either download the latest files from the symfony wiki or you can checkout the SVN version.

Install the plugin

symfony plugin-install http://plugins.symfony-project.com/sfPokaYokePlugin

Add the sfPokaYoke filter to your app filters.yml

rendering: ~
web_debug: ~
security: ~

# generally, you will want to insert your own filters here

poka_yoke:
class: sfPokaYokeFilter

cache:     ~
common:    ~
flash:     ~
execution: ~

Clear you cache

symfony cc

You’re done. Any forms that have validation rules will have client-side rules applied too. sfPokaYoke looks for validation rules that match the action name the form will be submitted to. This will also now work with named routes.

Usage Example

Once any validation rules are applied to the actions for your form, rules will be created for the client-side validation.

You can configure the client side validation to be triggered on the form submit or when the individual field loses focus. This is done by adding config values to your app.yml and will define how sfPokaYokePlugin responds to the users interaction

If the input value fails any validation rules that error will be inserted next to the input.

You do not need to add any <div> tags to capture these in-line errors unless you have a specific location in you form markup where you wish the error to be displayed. sfPokaYoke will look for the symfony form error locations and use those <div> tags if available.

If your template includes the following symfony form helper, sfPokaYoke will insert the errors into this location.

<?php echo form_error('name') ?>

On form submission a list of all error is inserted as the first child of the form. Each listed error item has an onclick event attached to allow the user to click on the error to focus the form field and resolve the problem.

<ul id="pkykGlobalErrors">
   <li class="globalErrorTitle">The following form information has been completed but it contains errors:</li>
   <li class="errors" id="pkykGlobal_username">Please enter your username.</li>
   <li class="errors" id="pkykGlobal_password">Please enter your password.</li>
</ul>

As each input error is corrected by the user the in-line and list errors are removed.

Example configuration

The code block below is an example app.yml file entry to configure the interactions of sfPokaYoke

all:
  # Example app.yml config for sfPokaYoke
  pokayoke:
    # Turn PokaYoke on and off
    on: true
    # Turn on the debuging this will cause alerts at each validation action
    debug: false
    # Event hooks - validation called on both field blur and form submit
    validate_onblur: true
    validateon_submit: true

    # Define which events should display the inline and global form errors
    display_inline_onblur: true
    display_inline_onsubmit: false
    display_global_onblur: false
    display_global_onsubmit: false

    # Inline error id="error_for(_name)" and class="form_error"
    inline_id_prefix: error_for_
    inline_class: form_error

    # <li class="form_error"></li> the global error lost class
    global_class: form_error
    # The text used to introduce the global errors list
    global_title: 'The following form information has been completed but it contains errors:'
    global_titleclass: pkyk_global_title

    # Add an onClick event to the items in the global list - click to focus the field with the error
    global_onclick_focus: true;

Related Articles

• No Related Post