"Quinton McCombs" <[EMAIL PROTECTED]> writes:
>Please note, that the event that I am talking about is NOT the session
>unbind itself. It is when the user object is removed from the session.
Ok. As I said, I wasn't sure if I grabbed the point of your argument.
>This happens on logout (because the anonymous user replaces the
>authenticated one on the session) and session timeout.
>We have the following cases:
>1. The user does not log out and the session timesout.
> Current: The entire user object is written to the database
> Proposed change: Only last login date, access counter, and persistent
>pull tools would be saved
So the LogoutAction should call a "DisposeUser" or
"putAuthenticatedUser" method in the SecurityService to return the
User object to the service. Think of it as ending the life cycle of
the user object. Its factory (which is the SecurityService that
returned it from getAuthenticatedUser()) should dispose it.
Doing this in a completely different Service is IMHO at least a layer
violation. And your Session Service has no idea whether the object is
writeable at all.
>2. The user logs out. Session timesout later.
> Current: Although the Logout Action appears to be written to save the
>user object, it doesn't. The user is not in RunData when the Logout
That's IMHO a bug.
>action executes. This becomes the same use case as #1
It is not? Where is it? It should be there. Are you sure about this?
> Proposed change: Same as #1.
No. Fixing the Logout Action is the correct change.
>This brings up the obvious question. How are changes made to the cached
>user object going to be saved? They aren't. If changes need to be made
>to the user object, the security service should be called to write the
>updates.
Yep. Did you get my mail about the Password changes?
Regards
Henning
>> -----Original Message-----
>> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, January 07, 2003 6:19 AM
>> To: [EMAIL PROTECTED]
>> Subject: Re: Discussion on TTWS30 - Session unbind causes
>> TURBINE_USER to be updated
>>
>>
>> "Quinton McCombs" <[EMAIL PROTECTED]> writes:
>>
>> >I have implemented the fix mentioned in the previous
>> message. There is
>> >one small difference...
>>
>> >I ended up saving everything that would be serialized into the
>> >OBJECT_DATA column on session unbind. This could pose a *small*
>> >problem for anyone using the permData hashtable for storage of extra
>> >data.
>>
>> >If no one objects to this, I will commit the changes in the next few
>> >days.
>>
>> Quinton,
>>
>> I was thinking about your statement and while I might not
>> having gotten exactly the point, please note one thing I fell
>> into headfirst a while ago:
>>
>> "The lifetime of a Turbine Session (and connected with
>> it the lifetime of the User object) differs from the
>> lifetime of a Servlet Session!"
>>
>> Please make this a mantra you repeat every time you work on
>> session management. I had to. :-)
>>
>>
>> Look:
>>
>> ---> -------------------------> time -------------------------> --->
>> | | | |
>> Servlet Session bind | | Session unbind
>> | | | |
>> | | | |
>> v | | v
>> Bind Event | | Unbind event
>> | | | |
>> v | | v
>> Turbine inits an | | Session expires
>> anonymous user object | |
>> v v
>> Login -> Turbine creates -> Logout
>> an authenticated
>> user object
>>
>> So neither the (container provided) session binding event nor
>> session unbinding have actually anything in common with the
>> lifetime of the Turbine User object (though if the user does
>> not log out but lets his session expire, these events match.
>> But this is nothing you can really rely on)!
>>
>> I'm quite scared if you move User object related
>> serialization into Session related events. These don't match.
>> What if an user logs out and logs on again in the same
>> session as another user? What if an user logs out (destroys
>> the user object) and the session expires some ten minutes later?
>>
>> The session information is nice for "knowing how many current
>> sessions are running and who logged on". But for nothing much
>> else, unless we redefine the session management
>> (SessionValidator, AccessController (Trust me, we won't)).
>>
>> Regards
>> Henning
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen --
>> Geschaeftsfuehrer
>> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
>>
>> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
>> D-91054 Buckenhof Fax.: 09131 / 50654-20
>>
>> --
>> To unsubscribe, e-mail:
>> <mailto:turbine-dev-> [EMAIL PROTECTED]>
>> For
>> additional commands,
>> e-mail: <mailto:[EMAIL PROTECTED]>
>>
>>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
