In ColdFusion, why shouldn't a Set & Forget child thread have access to session/client scopes?

Question

Threads spawned from a parent process in ColdFusion have access to the Session and Client scopes, but only until the parent process completes; so if the thread continues to run beyond that time, attempting to read from or write to one of these scopes will presumably throw an error.

Why?

I understand with Client scope, as this could be stored in various places including cookies, so the child thread would need access to the parent process to set headers that would affect the cookies; but Session scope is always stored in memory and identified by the cfid/cftoken or jsessionid values, which wouldn't change under normal circumstances.

I can't think of a single good reason to block access to the session scope after the parent process completes; and it would be incredibly useful if it were allowed.

For instance, I want to run a long-running stored procedure when a user logs in, and store the result in their session to be accessed via Query of Queries on a few other pages. Except for this stored procedure, the login is processed more or less instantly; so by adding the proc, login gets slowed down. If I could spawn a Set-&-Forget thread to run the proc and store the result in the session, that would be ideal. I understand that in this case it's possible that the result would be needed before it was stored, but I would code around that.

So, if there's some valid reason to block this, what is it?

Answer 1

I would guess (and it's only a guess) that references to persistent scopes would intentionally be unavailable. Adam and the team would be the best to answer this, and Mike Brunt could probably chime in, but I would think it comes down to JVM memory management. References to those scopes could potentially send your memory utilization through the roof, on processes that are essentially hidden.

I spend a lot of time monitoring servers with FusionReactor. I have seen instances where a process never timed out, and was found to be running days later. This was fairly rare, but has happened on multiple occasions, and was typically tied to a db access thread where the db dropped the connection mid-stream. Now, imagine several similar incidents, accessing these scopes, and you can't find them. At that point, you've created your own memory leak that is nearly untraceable.

But, I'm guessing. Pure speculation. I can hear your frustration, and I think you should definitely pass the question on to Adam and the team.