RE: [CFCDev] DAO Question for Joe Rinehart

[SBarnes]

Title: RE: [CFCDev] DAO Question for Joe Rinehart

Exactly,   I mean also if you have a bean thats also shared amongst different threads and each thread manipulates seperate data from one another within the bean, thats perfectly legal i guess. In many ways, its why VO was i think formed, as also a preventative measure against sharing a reference of an actual object amongst many third parties - not sure.   Its just, "yes use byRef" but like anything in OO hehe use it with caution..   Scott.           From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stacy Young Sent: Thursday, 23 December 2004 9:00 AM To: cfcdev@cfczone.org Subject: RE: [CFCDev] DAO Question for Joe Rinehart Ah I see what ur getting at … I believe that’s only a potential issue if the bean/object/vo itself is in a shared scope. i.e. If I were performing two operations in two separate threads on object xyz (in which each thread obtained that reference via the application scope) then yes, I risk having both threads trying to manipulate the same object at the same time. On the other hand if my DAO is hanging around in application scope and I pass in two separate object references (in request scope) in two different threads then I’m good to go because I’m manipulating two different object instances.   Not trying to poke at ya…just clarifying for any newbies who are watching closely…   -Stace   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 22, 2004 5:26 PM To: cfcdev@cfczone.org Subject: RE: [CFCDev] DAO Question for Joe Rinehart   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. AVIS IMPORTANT WARNING 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. 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.