yes as a matter of routine, my tables usually have fields for:

createdby   (the userid of the person who created this record)
datecreated  (timestamp)
updatedby  (The userid of the last person to alter this record)
dateupdated (timestamp)

So the methods in the DAOs that manipulate the records need to be told who's
doing it.  Since DAOs dont know anything about the application, request or
session scopes, they have to be told what they need to know.   In this case
they dont need to know the curent time (thats from the getdate() function in
the database) but they do need to know the userid of the person initiating
this action.    My question was about the best way to pass this info in,
since the application doesnt .instantiate the dao directly, but through a
CFCFactory which knows everything it needs to know to instantiate any CFC
required.

When someone logs in, there is a userbean created in their session scope,
containing their name, userid, access rights and lots more depending on what
else happens in this site.

So the question is about this .....if there is only one CFCFactory created
as a singleton in the Application scope, all the users on the site are using
the same instance of the CFC to instantiate whatever CFCS they need.  Each
time, the CFC being created will need to be told who's the user, so it can
update any records it needs to update correctly.   Or perhaps it's better to
pass the userID into each method as it's called rather than into the init
method of the DAO cfc.

The options in my first post were the ones that came to mind as i wrote it,
but there are probably other possibilities

What's brought this to mind now is that i'm working on an app that will have
maybe 150-200 concurrent users, all accessing, creating and updating
records.  In the past i've had plenty of reasonably high traffic sites, but
none with that many users creating and updating records simultaniously.  The
high traffic has all been in the read only category,with the write/update
being one or two people at a time max. Under those low traffic situations it
doesnt really matter to have everyone with their own CFCFactory.   One or
two fo them in RAM isnt a big deal   100-200 of them would definitely have a
performance hit on the site so i can't do that here.

Thats' the background to my question.

Cheers
Mike Kear
Windsor, NSW, Australia
Adobe Certified Advanced ColdFusion Developer
AFP Webworks
http://afpwebworks.com
ColdFusion, PHP, ASP, ASP.NET hosting from AUD$15/month


On 1/9/07, Josh Nathanson <[EMAIL PROTECTED]> wrote:
>
> It seems like option [B] would use a lot less memory resources.
>
> A little more detail about how your objects are set up would be helpful to
> get a clearer picture.  Do you have multiple tables which each store which
> user/ when created?  It seems like you could have a userID property in
> each
> of your objects that needs to maintain the user info, then do:
>
> myObject.setUserID(session.userbean.getUserID())
>
> before commiting. Then have timestamp field in the db.
>
>
>


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Create robust enterprise, web RIAs.
Upgrade & integrate Adobe Coldfusion MX7 with Flex 2
http://ad.doubleclick.net/clk;56760587;14748456;a?http://www.adobe.com/products/coldfusion/flex2/?sdid=LVNU

Archive: 
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:265979
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4

Reply via email to