Thanks everyone.
existingSession() seems pointless in my case, as it will always return null for
these actions, because there is no way for the callers to identify an existing
session.
I'm currently experimenting with stateless components. I didn't really look at
this from the perspective of t
Don’t create sessions in your Direct Actions.
Use existingSession() rather than session() (latter will create one if there
isn’t one). For example:
/**
* Do we have a current and valid logged in user?
* This method is careful not to create a session if one does not exi
…but if you want to discover where sessions are being created,
Application.createSessionForRequest() is certainly an excellent way to do it.
@Override
public WOSession createSessionForRequest( WORequest request ) {
Thread.dumpStack();
return super.createSessionForRequest( request
Hi Maik,
Sounds like your application doesn't actually need sessions. I’d start by
looking at where sessions are being created and then try to eliminate session
creation altogether. Unless session() is explicitly invoked in your DAs or
components, requests will generally not create new sessions.
Maik,
Why not use stateless components and avoid session creation all
together?
Michael Kondratov
Aspire Auctions, Inc.
216-231-5515
> On May 31, 2016, at 11:35 AM, Musall Maik wrote:
>
> Hi all,
>
> in an application that gets frequent DirectAction calls from other
> applications, I
Hi all,
in an application that gets frequent DirectAction calls from other
applications, I'd like to reduce the overhead of creating a new session for
every request. Currently I'm setting a short timeout, but creating and removing
all those sessions seems like avoidable overhead.
How about ove