Well, if you only have *one* piece of code that references the actual session scope then it's a step in the right direction - but how do your other components see the user's session(s)? If they just directly reference the request scope most would agree that's a bad architectural decision (violates encapsulation, etc etc).
-Dave On 6/25/06, Richard <[EMAIL PROTECTED]> wrote:
Thanks for the advice Dave Not sure I quite understand abstracting session management. I duplicate session structures at the top of each request, so I don't actully reference session.anything in the bulk of the code - Cheers -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Ross Sent: 25 June 2006 15:14 To: [email protected] Subject: Re: [CFCDev] Instances and persisted data session.user and database.user should be the same thing, meaning if the user "edits their data", they edit the session object which at the same time is comit back to the db. So yes I would do it at the same time. You might want to commit and then "refresh" the session object (fetch back from the db) if you are worried about inconsistancies. For the second issue, you could either ignore it (if you have two sessions, one will become "old" and the user would have to re-authenticate to get the updated data. If you *must* tackle this issue, then you'll need to track all your sessions (key them by userid) and then when an update occurs refresh all known sessions of that user. This is a perfect example of why it's a good idea to abstract session management (versus referencing session.* everywhere): you should be able to bolt on session tracking without touching any code other than your session management service/facade/whatever you want to call it (I like "UsageSessionService"). ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
