OK, I see where I was getting mixed up. The session timeout can be a
different length than the process timeout. But in practice the session
ceases to persist on 4D unless it's active in a process. So when the
process providing the context for the session expires that 'session id'
Are you sure you have Automatic Session Management checked on Database
4D Internet Users Group (4D iNUG)
No direct experience on that, but here are some debugging ideas:
- Do you have all the parameters declared in On Web Connection and on Web
- Put a trace in On Web Session Suspend to see if the session is getting
suspended. Might be a bad timeout setting?
- Are you changing any
Well that's good news - and I must be inadvertently doing something to
subvert it. Have you stumbled onto things that do would cause 4D to ignore
On Fri, Apr 14, 2017 at 5:51 PM, John DeSoi via 4D_Tech <
> Hi Kirk,
> > On Apr 14, 2017, at 11:33 AM,
> On Apr 14, 2017, at 11:33 AM, Kirk Brooks via 4D_Tech <email@example.com>
> But that's not the way I see it actually work. A new process spins up each
> time new request comes in and gets assigned a new web session id which
> replaces whatever the 4DSID cookie is.
Since I'm focused on the webserver today, I'm coming back to not being
clear on the distinction 4D makes between a 'web session' and the 'web
process' when using automatic session management.
A web session, as I understand it, is an authorized connection between a
browser and the server and
Mail list logo