If the call stack for the 31st and 32nd queries (which should be the end of the application cycle) is the exact same as the 3rd and 4th queries at the beginning of the application cycle, I'd say there are a lot of bigger issues here. Instead of just raising a flag because the debug console says the queries are duplicated, you'll have to dig into the call stacks and figure out what's triggering the code on each side. The first two are definitely because the user data is unserialized out of the session, but I haven't a clue what the last two are for.

Instead of just raising a flag because the debug console says the queries are duplicated

? is a nice way to found issues
Hmm just making sure there wasn't some known session process or something. that's way i asked.

you'll have to dig into the call stacks and figure out what's triggering the code on each side.

The first two are definitely because the user data is unserialized out of the session, but I haven't a clue what the last two are for.

First ones:

Last ones:

if i'm reading the call stack correctly it seems is the system debug plugin that does the two extra queries...

Yep. After the issues at the end of 3.4, JSession was changed so that when you request all data from the store it returns a clone of the internal data object (the Registry). IIRC the unserialized JUser object is never directly stored back to the data object (or if it is it's through some wizardry of PHP) so the clone has a serialized version of the object that needs unserialized again.

At the end of the day context is important. I could have three modules all executing the same query:

SELECT * FROM jos_content WHERE id = 1;

The console would report duplicate queries but in context the only data source the modules are sharing is the database driver so it'd give a "valid" reason for the duplication. If they were going through the article model there'd only be one query because the MVC layer has data caching in front of it.

ok i understand now. closing.
thanks again for your explanation.