Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Session::start() - Bug / Performance Improvement


Go to End


2 Posts   1938 Views

Avatar
mightycoco

Community Member, 3 Posts

7 May 2011 at 3:56am

Hi there,

I found that when doing large operations in the backend (like a batch action is converting a lot of images to create their thumbnails, etc) i can't browse Silverstripe anymore until the operation was finished.
Interestingly i could open another browser and i was able to work in ss.

I was playing around with PHP and HTTPD to make it multi-threading etc. to no avail.

Today I found out that SS is starting every time you access the CSM (frontend + backend) a new PHP session
sapphire/core/Session.php - Session::start()
@session_start();

The thing is, nowhere in ss the session is closed. No i tried to put a @session_write_close(); right after the session was started. The session information is written to the file and the session file on disk is no more locked.

The question now: Is it REALLY safe, doing this? What could happen "if"... ?
I haven't found negative side-effects until now. Browsing in the CMS seems to be much performant as well.

Is this only a flaw in Silverstripe or was it done that way intentionally?

Thanks,
MC

The whole function in session.php:

public static function start($sid = null) {
self::load_config();
$path = self::get_cookie_path();
$domain = self::get_cookie_domain();
$secure = self::get_cookie_secure();

if(!session_id() && !headers_sent()) {
if($domain) {
session_set_cookie_params(self::$timeout, $path, $domain, $secure /* secure */, true /* httponly */);
} else {
session_set_cookie_params(self::$timeout, $path, null, $secure /* secure */, true /* httponly */);
}

// @ is to supress win32 warnings/notices when session wasn't cleaned up properly
// There's nothing we can do about this, because it's an operating system function!
if($sid) session_id($sid);
@session_start();
@session_write_close(); // CHANGED: MCO - can we do this here ???
}
}

Avatar
Willr

Forum Moderator, 5523 Posts

7 May 2011 at 3:02pm

But if you write the session to file at that stage what happens to the data when you set it using Session::set() further down the script? Perhaps you need to call the close in the inst_save() method in session - though you will still get the delay while everything loads as that will run after the response has been generated. The session unit tests may be of some use to help work out if there are any side effects.