changelog + doc fixes for C::P::Session

diff --git a/Changes b/Changes
new file mode 100644 (file)
index 0000000..50542d5
--- /dev/null
+++ b/Changes
@@ -0,0 +1,12 @@
+Revision history for Perl extension Catalyst::Plugin::Session
+
+0.03
+        - Lazify loading of session data for better performance and less chance
+          of race conditions
+
+0.02    ???
+        - Doc fixes
+        - No more -Engine=Test
+
+0.01    ???
+        - Initial release.

diff --git a/lib/Catalyst/Plugin/Session.pm b/lib/Catalyst/Plugin/Session.pm
index 91c220e..969b48a 100644 (file)
--- a/lib/Catalyst/Plugin/Session.pm
+++ b/lib/Catalyst/Plugin/Session.pm
@@ -588,6 +588,8 @@ This value is only populated if C<verify_address> is true in the configuration.
 
 =head1 CAVEATS
 
+=head2 Round the Robin Proxies
+
 C<verify_address> could make your site inaccessible to users who are behind
 load balanced proxies. Some ISPs may give a different IP to each request by the
 same client due to this type of proxying. If addresses are verified these
@@ -599,6 +601,48 @@ that it's OK for the address of the client to change. When the server sees that
 this box is checked it should delete the C<__address> sepcial key from the
 session hash when the hash is first created.
 
+=head2 Race Conditions
+
+In this day and age where cleaning detergents and dutch football (not the
+american kind) teams roam the plains in great numbers, requests may happen
+simultaneously. This means that there is some risk of session data being
+overwritten, like this:
+
+=over 4
+
+=item 1.
+
+request a starts, request b starts, with the same session id
+
+=item 2.
+
+session data is loaded in request a
+
+=item 3.
+
+session data is loaded in request b
+
+=item 4.
+
+session data is changed in request a
+
+=item 5.
+
+request a finishes, session data is updated and written to store
+
+=item 6.
+
+request b finishes, session data is updated and written to store, overwriting
+changes by request a
+
+=back
+
+If this is a concern in your application, a soon to be developed locking
+solution is the only safe way to go. This will have a bigger overhead.
+
+For applications where any given user is only making one request at a time this
+plugin should be safe enough.
+
 =head1 AUTHORS
 
 =over 4