In this case, you don't really have a race condition as long as there's no modification made to the data while their local/cached copy is being read/has been read by other processes. It doesn't look like you have any changes going on, per your description, in which case you are safe! It can be read across as many processes as your memory/system/architecture support it without any consequence to the data itself.
Prashant On Tue, Mar 29, 2011 at 4:04 PM, Doug Boude <[email protected]> wrote: > Thanks, I appreciate the input! > > There are really no specifics to share, I'm in the process of architecting > a class and am just "thinking through" the aspect of thread safety with > regard to an internal data structure since this particular class will be > instantiated as a singleton and shared across sessions. What I meant by race > condition (though it is strictly my own understanding of it) is just two > method calls attempting to access the same in-memory data structure (be it > an object, array, associative array, or whatever) at the exact same time in > a read-only fashion. Was just wondering if such a situation would cause any > kind of issues or if both processes truly are able to traverse that same > data structure concurrently. In theory. :) > > > On Tue, Mar 29, 2011 at 3:58 PM, Jonathon Wilson <[email protected]>wrote: > >> All web servers (worth their salt) have some notion of concurrency. It's >> hard to say without seeing code, but it's certainly possible to get read >> requests before you've finished writing the initial structure. This in >> itself isn't really a race condition -- you just read it on one state and it >> changed later. >> >> The classic "race condition" comes when process A reads the data, then >> process B reads the data.. then process A *changes* the data, and then B >> uses his copy of the data (which is now stale) to overwrite process A's >> changes with his own. >> >> If your processes aren't changing anything, it's likely not a race >> condition. Can you describe what the problem actually is without giving away >> trade secrets? :) >> >> >> >> On Tue, Mar 29, 2011 at 3:47 PM, Doug Boude <[email protected]> wrote: >> >>> It's Coldfusion...Java based tag library. So, Java under the hood. >>> >>> On Tue, Mar 29, 2011 at 3:44 PM, Jonathon Wilson >>> <[email protected]>wrote: >>> >>>> If there's nothing that can possibly be modifying the data, there should >>>> be no risk of race conditions (in general). Sometimes, however, there *is* >>>> the possibly that something is modifying the data that you don't know >>>> about. >>>> What's the language? Environment? >>>> >>>> -- >>>> Our Web site: http://www.RefreshAustin.org/ >>>> >>>> You received this message because you are subscribed to the Google >>>> Groups "Refresh Austin" group. >>>> >>>> [ Posting ] >>>> To post to this group, send email to [email protected] >>>> Job-related postings should follow http://tr.im/refreshaustinjobspolicy >>>> We do not accept job posts from recruiters. >>>> >>>> [ Unsubscribe ] >>>> To unsubscribe from this group, send email to >>>> [email protected] >>>> >>>> [ More Info ] >>>> For more options, visit this group at >>>> http://groups.google.com/group/Refresh-Austin >>>> >>> >>> -- >>> Our Web site: http://www.RefreshAustin.org/ >>> >>> You received this message because you are subscribed to the Google Groups >>> "Refresh Austin" group. >>> >>> [ Posting ] >>> To post to this group, send email to [email protected] >>> Job-related postings should follow http://tr.im/refreshaustinjobspolicy >>> We do not accept job posts from recruiters. >>> >>> [ Unsubscribe ] >>> To unsubscribe from this group, send email to >>> [email protected] >>> >>> [ More Info ] >>> For more options, visit this group at >>> http://groups.google.com/group/Refresh-Austin >>> >> >> -- >> Our Web site: http://www.RefreshAustin.org/ >> >> You received this message because you are subscribed to the Google Groups >> "Refresh Austin" group. >> >> [ Posting ] >> To post to this group, send email to [email protected] >> Job-related postings should follow http://tr.im/refreshaustinjobspolicy >> We do not accept job posts from recruiters. >> >> [ Unsubscribe ] >> To unsubscribe from this group, send email to >> [email protected] >> >> [ More Info ] >> For more options, visit this group at >> http://groups.google.com/group/Refresh-Austin >> > > -- > Our Web site: http://www.RefreshAustin.org/ > > You received this message because you are subscribed to the Google Groups > "Refresh Austin" group. > > [ Posting ] > To post to this group, send email to [email protected] > Job-related postings should follow http://tr.im/refreshaustinjobspolicy > We do not accept job posts from recruiters. > > [ Unsubscribe ] > To unsubscribe from this group, send email to > [email protected] > > [ More Info ] > For more options, visit this group at > http://groups.google.com/group/Refresh-Austin > -- Our Web site: http://www.RefreshAustin.org/ You received this message because you are subscribed to the Google Groups "Refresh Austin" group. [ Posting ] To post to this group, send email to [email protected] Job-related postings should follow http://tr.im/refreshaustinjobspolicy We do not accept job posts from recruiters. [ Unsubscribe ] To unsubscribe from this group, send email to [email protected] [ More Info ] For more options, visit this group at http://groups.google.com/group/Refresh-Austin
