I'm not sure what you mean in a sense as to "additional load". What I was trying to illustrate was that if you have a bean, and you pass that around various objects within various "threads", the data within can be considered out of sync depending on the context of its use. I was merely providing an example of how sometimes byREF isn't always the answer and byValue could be a safer bet.
Probably not the best example looking back on it now heh - but what I was trying to say was that if you use setXXXX() in one thread, and in another thread you setXXXX() which populates say all the arguments within the bean. Then the bean kind of starts becoming a liability in that, if two threads are using the same methods (and one hasn't been validated while the other has etc), something outside of them needs to be not only mindful of it but adjust logic accordingly. Its not always a clear / cut / dry case but in other languages which have threading, I've found at times byValue is of no *pun* intended, better value in similar circumstances :)
There are a number of ways to counteract thread conflicts but for basic illustration of why you'd want to return say a bean out, I felt this would be a simple example. Maybe not :) heheh
Ignore me, I'm just killing time until santa arrives :D
Scott.
Pattern Code Monkey.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of Stacy Young
> Sent: Wednesday, 22 December 2004 5:12 PM
> To: [email protected]
> Subject: RE: [CFCDev] DAO Question for Joe Rinehart
>
> Hi Scott, I'm not sure I see how additional load would
> adversely affect any object references. Not trying to be
> snarky, just making sure I'm not missing anything obvious. ;-)
>
> -Stace
>
> ________________________________________
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 22, 2004 1:43 AM
> To: [email protected]
> Subject: RE: [CFCDev] DAO Question for Joe Rinehart
>
> No, If your passing in a Bean by itself into a DAO or any
> object for that matter, any information set within the bean
> during multiple cycles is fine.
> Provided its in a procedural situation (i.e. step 1, then
> step 2 etc). If you then start to play with threading, that's
> when it can get a bit tricky in regards to byRef as in future
> (blackstone appears to have it now) if a bean is used in one
> or more threads, the data comparisons between the two would
> get dysynched (heh especially if both threads invoke the same
> method(s)). So this is a case where passing in a
> snapshot/instance of the bean itself and returning it out is
> a more suited solution, as then the controller can marry up
> data via an onComplete event or something like that.
> Bottom line, so far its easy street and aok to pass things
> around byRef, but when things heat up into threading, that's
> where you start weighing that concept up - probably won't
> happen all that often as yet, but its just food for future thought.
> Regards
> Scott Barnes.
> Pattern Code Monkey.
> �
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] On Behalf Of Dawson, Michael
> > Sent: Wednesday, 22 December 2004 4:02 PM
> > To: [email protected]
> > Subject: RE: [CFCDev] DAO Question for Joe Rinehart
> >
> > >> Can't speak for Joe, but how you implement the CRUD routines is
> > entirely up to your space in life. If the Update() not only adds
> > information to the persist layer but contributes information to the
> > bean (ie dtPersistTimeStamp = Now()) then that can be considered a
> > valid reason for returning it back out provided your in the
> context of
> > byRef of the bean..(ie not shared amongst other objects aka
> byValue -
> > probably loosing it in translation here but lets say if you change
> > stuff in the bean/DTO it won't reflect unless being passed out).
> >
> > After I sent my email, the idea of adding a timestamp came
> to me.� I
> > am passing by reference, so is there any need of returning another
> > (read:
> > same) instance from the method since I can just stick the timestamp
> > directly in the original instance?
> >
> > >> You could pass in an ID if the Read() routine is a simple db call
> > (which is your judgement call), and it will exist for the
> life of that
> > application. You could pass in a bean to act as a DTO in the end if
> > there is lots of arguments required to extract the data in question
> > (ie file location or multiple tables etc) - again your own
> judgement
> > call.
> >
> > As I said, whatever blows your hair back - I think its not
> meant to be
> > taken as gospel but merely a code illustration of the DAO concept
> > being applied.
> >
> > Regards
> > Scott Barnes.
> > Pattern Code Monkey.
> >
> >
>
>
>
> <table width=800 cellpadding=4 cellspacing=10 border=0><tr
> bgcolor=BDBDBD><td valign=top width=400><font face=verdana
> size=2 color=FFFFFF><b>AVIS IMPORTANT</b></font></td><td
> valign=top width=400><font face=verdana size=2
> color=FFFFFF><b>WARNING</b></font></td></tr><tr><td
> valign=top width=400><p align=justify><font face=verdana
> size=1 color=808080> Les informations contenues dans le
> present document et ses pieces jointes sont strictement
> confidentielles et reservees a l'usage de la (des)
> personne(s) a qui il est adresse. Si vous n'etes pas le
> destinataire, soyez avise que toute divulgation,
> distribution, copie, ou autre utilisation de ces informations
> est strictement prohibee. Si vous avez recu ce document par
> erreur, veuillez s'il vous plait communiquer immediatement
> avec l'expediteur et detruire ce document sans en faire de
> copie sous quelque forme.</td><td valign=top width=400><p
> align=justify><font face=verdana size=1 color=808080> The
> information contained in this document and attachments is
> confidential and intended only for the person(s) named above.
> If you are not the intended recipient you are hereby notified
> that any disclosure, copying, distribution, or any other use
> of the information is strictly prohibited. If you have
> received this document by mistake, please notify the sender
> immediately and destroy this document and attachments without
> making any copy of any kind.</td></tr></table>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by
> Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
