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 the response components. In addition to that, I
needed to eliminate several session() references in my DA actions, but those
were mostly just logging the session ID to help determine where all those
sessions came from ;-)
So far it looks good, now running in staging environment.
Thanks again
Maik
> Am 31.05.2016 um 18:41 schrieb Mark Wardle <m...@wardle.org>:
>
> 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 exist.
> * @return
> */
> public boolean isLoggedIn() {
> Session session = (Session) existingSession();
> if (session != null) {
> return session.isUserAuthenticated();
> }
> return false;
> }
>
>
>> On 31 May 2016, at 16:35, Musall Maik <m...@selbstdenker.ag
>> <mailto:m...@selbstdenker.ag>> wrote:
>>
>> 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 overriding WOApplication.createSessionForRequest()? I could try to
>> determine if it was called from within DA processing, and then return a
>> pooled session, but as I see it I'd have to fiddle with the
>> _activeSessionsCount to compensate, and I suspect the rest of WOApplication
>> always expects this method to return a newly created session.
>>
>> So, does anyone else do something similar?
>>
>> Thanks
>> Maik
>>
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com
>> <mailto:Webobjects-dev@lists.apple.com>)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org
>> <https://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org>
>>
>> This email sent to m...@wardle.org
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
