Thank Kieran, i am going with the
Saun's suggestion as it fits nicely with what i have done so far. I
also don't to add even more complexity to this already complex system
as a whole.
thanks
Peter
Kieran Kelleher wrote:
This approach might work for you .... or not if I have
misunderstood your domain problem ....
1) Have a PendingLogout entity (aka table) which represents a
queue of sessions to be logged out .... one attribute is the sessionID.
The PendingLogout EO's are created by your code that detects that the
session is no longer valid.
2) Have a separate small LoggerOuter.woa app that accesses the
same database table and fetches the PendingLogout objects periodically
and sends a direct action logout request including the session ID to
the real app with the session .... thereby simulating a real user
logging out in an R-R loop.
3) The log out action could also delete the record from the db
YMMV,
HTH, Kieran
On Aug 28, 2007, at 7:39 PM, Peter Vandoros wrote:
We have
a situation where we Single Sign On with a 3rd party system. When the
user SSO's into our system, we need to keep their session alive in that
3rd party system for when the user re-enters that system. We do this by
having a set of TimerTask's firing every X minutes. The idea is that if
we detect that the user's session in the 3rd party system is no longer
valid, we have to kick the user off our session. Essentially, logging
the user out of our system.
In this case, we need access to our WOSession in order to log the user
out.
Thanks
Peter
Chuck Hill wrote:
On Aug 27, 2007, at 10:25 PM, Peter Vandoros wrote:
What if I access and use a WOSession
outside of the request-response loop? Do i have to ensure that i call
WOApplication.saveSessionForContext() when i am done using it?
Yes, that is what checks it back in.
May I ask why you want to access the session outside of a RR loop?
Perhaps there is a better way to do what you need done.
Chuck
Chuck Hill wrote:
On Aug 27, 2007, at 12:51 AM, Peter Vandoros wrote:
Hi List,
I was wondering how WebObjects enforces serial access to the WOSession
(ie. request processing).
Does the "wo" request handler enforce serial access? Does the"wa"
request handler enforce serial access? Does
Application.dispatchRequest() enforce serial access?
Also, if I was to access a WOSession outside of a request-response
loop, how can I ensure that the WOSession is not processing a request
at the same time? How can I ensure that only one Thread accesses the
WOSession at a time that comes from a "da" request? How do I initialise
the WOSession correctly if I need access to it when not coming from a
"wo" request the "wosid" is not sent along with a "wa" request?
See WOSessionStore and related methods in WOApplication. See Practical
WebObjects pages 171 - 172,
Is
WOApplication.restoreSessionWithID() going to do "the right thing" when
ever I call it? ie. is it going to initialize the WOSession correctly?
will it ensure serial access to the WOSession? etc...
Yes.
Chuck
--
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are confidential and
may be privileged. If received in error, please reply to this message
and destroy all copies and any attachments. You should check this
message and any attachments for viruses or defects. Our liability is
limited to resupplying any affected message or attachments. For more
information about Etech Group, please visit us at http://www.etechgroup.com.au.
--
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are confidential and
may be privileged. If received in error, please reply to this message
and destroy all copies and any attachments. You should check this
message and any attachments for viruses or defects. Our liability is
limited to resupplying any affected message or attachments. For more
information about Etech Group, please visit us at http://www.etechgroup.com.au.
_______________________________________________
Do not post admin requests to the list.
They will be ignored.
Help/Unsubscribe/Update your Subscription:
--
This message has been scanned for viruses and
dangerous content by
MailScanner,
and is
believed to be clean.
--
Peter Vandoros
Software Engineer
Etech Group Pty Ltd
Level 3/21 Victoria St
Melbourne VIC 3000
Australia
Ph: +61 3 9639 9677
Fax: +61 3 9639 9577
----------------------------------
IMPORTANT: This e-mail message and any attachments are confidential and
may be privileged. If received in error, please reply to this message
and destroy all copies and any attachments. You should check this
message and any attachments for viruses or defects. Our liability is
limited to resupplying any affected message or attachments. For more
information about Etech Group, please visit us at
http://www.etechgroup.com.au.
|