DISQUS

Ivan V. · 1 year ago

So, this plugin only works with MySQL right? Are you considering supporting other DBs, like postgresql?

Thanks.

Scoundrel · 1 year ago

I do not work with postgres, but patches are welcome :-)

Ivan V. · 1 year ago

I'm no expert at all on databases, but I'll see what I can do :)

Chris · 1 year ago

Why don't you just use the cookiestore in rails 2.0? That way you don't need to store sessions in the database at all!

Matthias · 1 year ago

the self.delete_old! method did not work for me. I changed it to:

@@connection.execute "DELETE FROM #{table_name} WHERE UNIX_TIMESTAMP(updated_at)

Matthias · 1 year ago

< UNIX_TIMESTAMP(NOW()) - #{seconds}"

Note the UNIX_TIMESTAMP around (updated_at) in first part of the comment

Drew Blas · 1 year ago

You mentioned turning off sessions from bot requests, but didn't mention how. Here's my method:

[application.rb]
# turn off sessions if this is a request from a robot
session :off, :if => proc { |request| request.user_agentuser_agent =~ /\b(Baidu|Gigabot|Googlebot|libwww-perl|lwp-trivial|msnbot|SiteUptime|Slurp|WordPress|ZIBB|ZyBorg)\b/i }

Andrey · 1 year ago

Of course, it's a little bit artificial case, but when session size exceed 70kb I become error (code 500). Log says that sql connection lost during update operation.
After that application don't get back alive, until I delete session record.

Eric · 1 year ago

What about using MyISAM for the sessions table. Implications, like for instance, table locking during updates/additions?
Unfortunately, my MySQL database was not compiled with InnoDB.

Eric · 1 year ago

What would the impact be for using fast_sessions with MySQL and MyISAM tables as opposed to InnoDB (table vs. row level locking)? Any thoughts?

Paolo Montrasio · 1 year ago

There is a plugin called SmartSessionStore that does more or less the same and works also with PostgreSQL. I've been using it for almost an year in production with no problems at all.

Andrew Watkins · 1 year ago

We're using postgresql and actually ported it over, except for one problem: Postgresql does have crc32 as a function. You can kind of get there by either writing your own or installing the one with ltree. Postgresql does however have md5. What we did is setup tests against unique(md5_session_string, session_id), unique(crc32, session_id), and unique(md5_session_byte,session_id). The last one is a byte representation of the md5 hash. For random queries, the 1st two implementations ran at about the same speed, which was basically instantaneous. The byte one definitely showed a little lag, and so would not recommend it. Finally we created a stored procedure to actually handle the insert/update as postgresql doesn't have a "ON DUPLICATE KEY UPDATE". The question is whether or not this is faster than just indexing the session_id itself or is something screwy is going on where postgresql is optimizing against the hashed values.