Re: Avoiding session creation for DirectActions

2016-06-01 Thread Musall Maik 
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 :
> 
> 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 > > 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 
>> )
>> Help/Unsubscribe/Update your Subscription:
>> 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

Re: Avoiding session creation for DirectActions

2016-05-31 Thread Mark Wardle 
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  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)
> Help/Unsubscribe/Update your Subscription:
> 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

Re: Avoiding session creation for DirectActions

2016-05-31 Thread Hugi Thordarson 
…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 );
} 

- hugi


> On 31. maí 2016, at 15:39, Hugi Thordarson  wrote:
> 
> 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.
> 
> - hugi
> 
> 
> 
>> On 31. maí 2016, at 15:35, Musall Maik  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)
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is
>> 
>> This email sent to h...@karlmenn.is
> 
> 
> ___
> 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/hugi%40karlmenn.is
> 
> This email sent to h...@karlmenn.is


 ___
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

Re: Avoiding session creation for DirectActions

2016-05-31 Thread Hugi Thordarson 
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.

- hugi



> On 31. maí 2016, at 15:35, Musall Maik  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)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/hugi%40karlmenn.is
> 
> This email sent to h...@karlmenn.is


 ___
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

Re: Avoiding session creation for DirectActions

2016-05-31 Thread Michael Kondratov 
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'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)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/michael%40aspireauctions.com
> 
> This email sent to mich...@aspireauctions.com


 ___
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