CI 1.6 sessions

[eluser]FlashUK[/eluser]
Ahh I see what you mean. I hadn't thought about that. I had only been reading it as you had written it.

It would seem more efficient to strip the else tags from the statement (not that it really matters).

I'm going to continue looking at it since I'm pondering about my login system at the same time and how I am going to use this.

[eluser]webthink[/eluser]
I know it's late and probably discussed elsewhere but I wanted to point out a problem with EugeneS' argument that native sessions are better for performance. Storing sessions in the db is not necessarily slow and is infinitely more scalable.
Anybody who has ever designed a system with enough traffic to require it to run on more than one application server can see the problem with native sessions. As a user I'm happily clicking away and my requests are going to server1 but suddenly load balancing decides to move me to server2. Where did my session go? oops.
The other part to the argument is that by making the table a memory table and or query caching you essentially boost the speed of a db based session to that of native sessions.
I just didn't want anyone stumbling across this thread and only seeing one side of the coin. Yes native sessions are fast for small sites that are sure to stay small. But if you expect to get any kind of traffic they are not scalable.

[eluser]EugeneS[/eluser]
[quote author="webthink" date="1204638162"]I know it's late and probably discussed elsewhere but I wanted to point out a problem with EugeneS' argument that native sessions are better for performance. Storing sessions in the db is not necessarily slow and is infinitely more scalable.
Anybody who has ever designed a system with enough traffic to require it to run on more than one application server can see the problem with native sessions. As a user I'm happily clicking away and my requests are going to server1 but suddenly load balancing decides to move me to server2. Where did my session go? oops.
The other part to the argument is that by making the table a memory table and or query caching you essentially boost the speed of a db based session to that of native sessions.
I just didn't want anyone stumbling across this thread and only seeing one side of the coin. Yes native sessions are fast for small sites that are sure to stay small. But if you expect to get any kind of traffic they are not scalable.[/quote]

disagree
1) if you ever worked in big projects located on many servers that you should know about synchronization - this is admin's area of expertise so if session will be stored in server 1 instead of server 2 fire your admin because it should be stored in 2 places the same time or smth similar (i have worked in such conditions so i dont know how its realized but i know synhro is usual thing for good admin) + as i said before if you have dedicated server for database then storing session in DB is not a problem but almost 80-90% of internet is on the shared hosting

2)query cashing - have you looked into the CI modules ? have you seen that data stored in the DB as a serialized array ? do you know that data in the native php sessions are stored as serialized array ? so no difference - this i not an argue ))) more over session class to store data in db doing many other things like quotation for example ... but this wont be required for native sessions (do not remember exactly just know there many additional actions) + but if site changing all the time data in the database (we have big project do you remember ?) in this case cashing useles because it will changed all the time and we have overloading .. i have to write data into the database all the time + i have to change all the time cashed sql ... even more server load ))

[eluser]webthink[/eluser]
Ok. I helped build a site that supported 15,000 concurrent users (usually averaged around 10,000 at a time) and ran across about 25 servers. Native sessions were the first thing that went away in favour of a custom session handler which used a combination of database based sessions (one of those 25 servers was dedicated solely to session db) and memcached. I wasn't in charge of making these decisions. We had an architect who's job it was to know everything about that stuff but I know what we implemented worked.

When you talk about sycronization I assume you mean something like zend's session clustering or storing them on an NFS file share which is a good solution, but it isn't the only one and it depends on your application's needs.

All I was really trying to do though was to point out that the simplistic view of db sessions = slow, native sessions = fast, while more accurate on a single server setup, is not showing the whole picture after all performance and scalability are two completely different things.