no guide for using dynamodb for session handling for 2.x API

[ralph-tice]

i'm still trying to figure out pull requests, so I've made a gist:
https://gist.github.com/4446893

this is intended to replace the instructions from http://aws.typepad.com/aws/2012/04/scalable-session-handling-in-php-using-amazon-dynamodb.html

it also pre-supposes installation of aws-sdk-php via composer

[jeremeamia]

Thanks! We are working on some end-user documentation on the docs branch. I'll have to add a page about the session handler soon.

[ralph-tice]

is there any reason not to use a github wiki?

[jeremeamia]

More flexibility. The docs branch is setup for static site generation with Sphinx and reStructured Text. That way we have flexibility in the location and look of the docs. There are several PHP projects using Sphinx for docs already. If you install it, you can generate the docs site locally right now with a single command. We just haven't published the site anywhere yet. With the holidays over now, we plan to get moving on this. Restructured text is very similar to Markdown, so we hope to have others contribute to the docs as well once we get the ball rolling.

[jeremeamia]

Hey,

We recently published our user guide here: http://docs.aws.amazon.com/aws-sdk-php-2/guide/latest/index.html.

I have written up a guide to the session handler that we'll be adding soon. Care to review? You can see the content here: https://github.com/jeremeamia/aws-sdk-php/blob/399d736a347d190e3d10883db413c371f593fd66/docs/feature-dynamodb-session-handler.rst. Let me know if you think anything is missing or could be clarified. Thanks.

[ralph-tice]

Just read through it and looks like you covered it all from the code side, but I think you should include the php.ini changes also. I don't think you should default to the php.ini gc probability if it's recommended to run it on a cron instead, and I think it's pretty important to run it on a cron instead of the default PHP way so you don't have throughput problems, but instead of changing functionality you could just say set this:
session.gc_probability = 0
and:
auto_prepend_file = /var/www/dynamodb_session_handler/register_sessionhandler.php
seem warranted to go over, unless there's a reason not to use auto_prepend.

[mtdowling]

@ralph-tice Thanks for your feedback.

I don't think you should default to the php.ini gc probability if it's recommended to run it on a cron instead, and I think it's pretty important to run it on a cron instead of the default PHP way so you don't have throughput problems, but instead of changing functionality you could just say set this:
session.gc_probability = 0

This is a tough one. While it isn't optimal, defaulting to these settings also allows the session handler to work in more restrictive PHP environments like shared hosting where users do not have access to the shell or cron.

auto_prepend_file = /var/www/dynamodb_session_handler/register_sessionhandler.php seem warranted to go over, unless there's a reason not to use auto_prepend.

I'm not a big fan of auto_prepend_file. It often leads to confusion because it fragments the bootstrapping process of an application. Another downside: what if you don't want all of your PHP scripts to start a session (e.g. command line scripts)?

[jeremeamia]

I don't want to suggest auto_prepend_file, because as Michael points out, it's not always good for every use case. It also makes it hard to reuse the same DynamoDB client in other parts of your app, which you definitely should try and do since you can take advantage of the persistent connection created the first time it's used and not have to make the SSL handshake again.

[ralph-tice]

After reading your comments I think you're both right about auto_prepend_file being pretty environment specific (and not generally a great idea).

Not sure I'm on the same page with the PHP directive -- does ini_set() address your particular concerns? Default PHP session GC behavior is really bad for a production DynamoDB table if you have lots of sessions created, you'll GC during peak and generally overrun your max throughput or be forced to over-provision.

[jeremeamia]

I added some more advisory text in this commit. Do you think that this helps?

[ralph-tice]

Yeah, that seems to cover all the bases.

[ffflabs]

I've seen no mention for session autostart setting, but at least for me dynamodb sessions just doesn't work,

I'm pretty happy with elasticache handling my sessions though, so I'm eager to see more sdk sintactyc sugar upcoming related to elasticache, wirh a good drop in replacememt for vanilla memcache drivers.

[jeremeamia]

@ralph-tice Thanks!

@amenadiel To address your comments…

I've seen no mention for session autostart setting

The session.auto_start setting is not meant to work with custom session handlers built for use with session_set_save_handler().

at least for me dynamodb sessions just doesn't work

What do you mean by this? Are you saying that you think there is a bug or that it just does not fit your use case?

I'm pretty happy with elasticache handling my sessions though

Sure, ElastiCache can also be a good solution for sessions.

I'm eager to see more sdk sintactyc sugar upcoming related to elasticache

Do you have any specific ideas for what we could do in the SDK?

a good drop in replacememt for vanilla memcache drivers.

The ElastiCache team has a custom memcache driver that supports auto discovery of all the nodes in your cache cluster. See Installing the ElastiCache Cluster Client for PHP in the ElastiCache service's Developer Guide.

[jeremeamia]

Closing this issue now. @amenadiel feel free to comment back on here if you get a chance. Thanks.

[jeremeamia]

The guide is now published: http://docs.aws.amazon.com/aws-sdk-php-2/guide/latest/feature-dynamodb-session-handler.html