CodeIgniter Forums
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;
unset($this->db);
$this->db = $this->load->database('session', TRUE);
$this->load->library('session');
$this->db = $this->default_db;
unset($this->default_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.