Hello, But If User Leave the system or Session Expires.The database is not updated from flag=1 to flag=0.This may lead to problems.I think you can preserver LastLogin time.i.e. When ever user log in we keep the User login information in db.If we are known with session time out peroid we can use that information to find out logged users.
If you can you can store the Information in Application variable a structure.But It has its own drawbacks. But Still you can give a try to one of the above. With Regards Nagaraj.A ----- Original Message ----- From: "Dimple Goshar" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Tuesday, April 23, 2002 3:05 PM Subject: RE: Keeping track of logged-in users... > Hi, > > If you want to avoid updates to your database, you can have another > column in your users database , "loggedon" which is set to > 1 when the user logs on to the site and set to 0 when the user logs > off > > Then u can give ur report on the basis of this column > > > Regards > Dimple > > > -----Original Message----- > > From: Kevin Langevin [SMTP:[EMAIL PROTECTED]] > > Sent: Tuesday, April 23, 2002 2:42 PM > > To: CF-Talk > > Subject: Keeping track of logged-in users... > > > > Hi all- Got a "best practices" question for you. > > > > I've got a client site which uses client variables to track users' > > sessions > > for auto-logout. When a user logs on, a CLIENT.lastAccess variable is set > > to now(). In the application.cfm, a check is run to see if > > CLIENT.lastAccess is defined and if it's more recent than 20 minutes. If > > it > > is, then CLIENT.lastAccess is set to now() again, and processing > > continues. > > As long as the client hits a page before the 20 minute time limit runs > > out, > > works great. To log the user out, I delete certain client variables, > > especially lastAccess. > > > > Now my dimlemma. The client decided that he wants to track how many users > > are "logged on" (how many have accessed a page in the last 20 minutes and > > haven't yet been logged off. > > > > The only way I can see to do this is to ALSO write now() into a lastAccess > > field in the member database on each hit right after writing the client > > variable, so that the home page, which is supposed to display the number > > of > > users logged in, can run a query on members with a lastAccess field with a > > time less than 20 minutes ago. This just seems like a lot of DB access > > (one > > write when setting the CLIENT variable, and another when updating the > > member > > table), but I'm wondering if anyone has experience doing something like > > this, and whether that one extra update on each page hit will hurt that > > much. Assume a few thousand members hitting the site daily, spread out, > > most likely, but probably surfing around a fair bit (lots of articles, and > > a > > message board). Doing the CLIENT variable update seems to impact the site > > not at all, but I've not tested under really heavy load. > > > > Does anyone have a more elegant way of doing this, like parsing the Client > > DB for the CLIENT.lastAccess variable and getting a count of the ones with > > a > > value less than 20 minutes ago. Any suggestions would be most > > appreciated. > > > > Thanks... > > > > Kevin Langevin > > Flying Chimp Media > > 954-585-0999 > > [EMAIL PROTECTED] > > http://www.FlyingChimp.com > > > > > -----Original Message----- > > > From: Neil Clark - =TMM= [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, April 23, 2002 4:51 AM > > > To: CF-Talk > > > Subject: RE: CF's Most Wanted :: > > > > > > > > > Hi Peoples > > > > > > Well, I can say, since its public knowledge in some circles that locking > > > will no longer be required with Neo - the server will handle this side > > > of things. CFMX has addressed the fact that failure to lock shared > > > scope vairables will not cause memory corruption while a write operation > > > is in progress. > > > > > > **However**, you will still have to lock for the legitimate use - to > > > prevent synchronous activity ensuring that requests are requests are > > > processed one at a time. For example, if I am about to reread a cached > > > query I might decide that all requests that need this query should wait > > > so as to ensure that they have the newer data. > > > > > > Hope this helps! > > > > > > > > > > > > > > > > > > Neil > > > Team Macromedia > > > http://www.macromedia.com/go/team > > > > > > > > > > > > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
