@innato I confirm you the issue 3.
I've already faced this problem in one extension of mine that heavily rely on the #__session metadata 'time' field.

I had to manage a fix in my extension using the following code:

// Patch for propagating DB session lifetime if the native PHP sessions handler is active
$config = JFactory::getConfig ();
if($config->get ( 'session_handler' ) != 'database') {
try {
$time = time();
// The modulus introduces a little entropy, making the flushing less accurate but fires the query less than half the time.
$query = $this->_db->getQuery(true)
->update($this->_db->quoteName('#__session'))
->set($this->_db->quoteName('time') . ' = ' . $time)
->where($this->_db->quoteName('session_id') . ' = ' . $this->_db->quote($this->userSessionTable->session_id));

			$this->_db->setQuery($query);
			$this->_db->execute();
		} catch (Exception $e) {
			// No errors managed, leave the process go on anyway
		}
	}

The time column isn't really considered part of the metadata aspect of that table and that's why we don't touch it (if you are using the database handler that does manage the time column; as there's no hook point when session data is written any updates to the time column would be arbitrary at best and still leave a lot of room for discrepancy if you're relying on that for something like determining expiry; this all isn't to say the behavior can't change but if someone's going to consider a patch the change has to be aware of the fact that the time column value MUST respect the value set by the session handler and not an outside thing like the metadata manager when the database handler is used as a backend otherwise you run the risk of a security issue related to sessions not expiring when intended, one more reason why mixing the two types of data into one table was IMO a not-so-great architectural decision).

Regarding item 1, there might be a semi-aggressive database query somewhere in the logout process, but when the database session handler is not in use the data in the session table is nothing more than a convenience for core features such as a list of logged in users or the frontend who's online module (or whatever extension integrations are made), the point of truth as it relates to sessions will be whatever engine is in use. So the fact these things "disappear and reappear" is at most annoying, at worst an inconvenience.

Also keep in mind the metadata storage process has been completely refactored in 4.0, to the point that if the data fails to write for whatever reason it is no longer considered a fatal error (in 3.x it is because the database session handler doesn't know how to perform an INSERT query), and that the configuration will allow processing of this metadata to be disabled. Now granted, the odds of the INSERT/UPDATE query for metadata failing and the rest of the request cycle completing successfully are going to be slim to none, but this does make it more theoretically possible that the metadata will be out of sync with the true session data source (unless your source is the database), where at worst you'd be missing the user and client IDs).

@mbabker Thanks for your valuable comments. You regard item 1 as annoying/inconvenient. I would rather call it sloppy. Same for item 2; if admin can't force a logout, then don't suggest it by displaying a red/white icon. As to the #_session table, an extension of mine depends on this table and indeed it needs up-to-date data for expiry reasons (also related item 3, the time field).
In your last comment, are you saying that things will be very different in J4.0 ? Would you say that the current release Alpha 3 is close to what the metadata storage will be? If so, I can start testing it. Or maybe I shall add an extra system plug-in to my extension to store the needed session data independently from the Joomla! core...

current release Alpha 3

current Release is https://github.com/joomla/joomla-cms/releases/tag/4.0.0-alpha4

Because j4 is developing rapidly its far better to grab the nightly release https://developer.joomla.org/nightly-builds.html

@innato As a developer you are welcome to submit a pull request to address the "sloppy" code

@brianteeman Just to make things clear... I didn't mean that the code is sloppy, but the outcome of it is. I hope you can give me some credit for not being a native English speaker. I have been doing Joomla! for ages (starting J1.0), but never got involved in pull requests, don't even know exactly what they are... I'll start reading about it. Rgrds.

I'll start reading about it.

https://docs.joomla.org/Filing_bugs_and_issues#Issue_a_pull_request_directly_on_Joomla.21.27s_GitHub_repository

You regard item 1 as annoying/inconvenient. I would rather call it sloppy.

Sloppy, inconvenient, at the end of the day it all basically means the same thing, something isn't behaving consistently.

As to the #_session table, an extension of mine depends on this table and indeed it needs up-to-date data for expiry reasons (also related item 3, the time field).

Unfortunately, unless you're using the database handler this isn't reliable. We generally write the metadata insert/update at the start of the request cycle, session data can be written at any time after. For quick requests that start/end in the same second this can be OK, but if you've got a long running request that rolls across seconds then the expiry timestamp in the session data and the timestamp in the session table (at that point only acting as a metadata store) would be out-of-sync. If you're relying on these to be 100% in sync that just won't happen. So even if we improve the handling here, it's not a safe value to rely on in all scenarios.

In your last comment, are you saying that things will be very different in J4.0 ?

The process on how the metadata is managed will be a bit different, as well as the ability to turn it off completely being present, but those internal changes shouldn't affect extensions using this data by the time all is said and done (there's an open issue somewhere detailing some remaining tasks to complete related to the session handling in general).

As to the #_session table, an extension of mine depends on this table and indeed it needs up-to-date data for expiry reasons (also related item 3, the time field).

To resoIve the issue in the least time-consuming way, I have added a simple system plugin to my extension, which updates the timestamp in the #__session table. The timestamp is not critical on a seconds time scale, so the out-of-sync issue that @mbabker mentioned is not a problem.

@innato is this an Issue anymore?

@franz-wohlkoenig I haven't checked the present Joomla! version 3.9.4, but if the issue has not been addressed in a Joomla! version after J3.9.1, then it will still exist. But as I commented on 28th Oct 2018, I have worked around it.
In case you're checking because the issue is still open, I will be happy to close it, as Joomla! 4 is on its way soon...

In case you're checking because the issue is still open, I will be happy to close it, as Joomla! 4 is on its way soon...

Yes, that was the Reason.

Thank you for waking me up. Issue closed.