Sessions in database other than default? - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: Using CodeIgniter (https://forum.codeigniter.com/forumdisplay.php?fid=5) +--- Forum: Installation & Setup (https://forum.codeigniter.com/forumdisplay.php?fid=9) +--- Thread: Sessions in database other than default? (/showthread.php?tid=64806) |
Sessions in database other than default? - mrosenello - 03-28-2016 Anyone have any ideas on the best way of going about storing ci_sessions on a database other than the default database? Thanks RE: Sessions in database other than default? - Avenirer - 03-31-2016 What is "the default database"? ...in your view... RE: Sessions in database other than default? - mrosenello - 03-31-2016 (03-31-2016, 07:18 AM)Avenirer Wrote: What is "the default database"? ...in your view... The one that is set in database.php by $db['default']. RE: Sessions in database other than default? - Narf - 03-31-2016 Do you mean the default database connection or the default schema (which MySQL ambiguously calls "database")? Using another schema should be easy. Using a different connection is ... technically possible, but doesn't make sense. RE: Sessions in database other than default? - mrosenello - 03-31-2016 I mean another connection. Our application is currently load balanced across 3 web servers with 2 database shards. The database we have set as the main connection handles the majority of transdactions/data storage. With the addition of ci_sessions to our "default connection" when we have spikes in traffic we see some performance issues as well as a spike in active threads mainly due to a stuck GET_LOCK query on the ci_sessions table. So I am looking to move this table over to its own database to see if it helps. RE: Sessions in database other than default? - Narf - 03-31-2016 It won't help ... You're shooting in the dark here and that rarely yields positive results. IMO, those GET_LOCK() queries aren't stuck ... they're waiting for RELEASE_LOCK() calls from other processes. To improve on that - call session_write_close() as soon as you no longer need to write new session data. If you still want to try, there's a little trick ... The documentation says you have to use the default connection because that's the one connection that's almost guaranteed to exist, but technically it just looks for get_instance()->db (and loads the 'default' connection if that doesn't exist) and creates a copy of it. So you can do something like this: Code: $this->default_db = $this->db; I wouldn't get my hopes up though ... I don't see how moving sessions to another database would help - GET_LOCK() will still block new requests until the lock is released. |