Dan - thanks for the suggestion, will look into this. Would you use a queue to keep them separate or how, at the controller event level do you prevent it from running two work tokens simultaneously?
On Tuesday, February 12, 2013 12:44:49 PM UTC-8, Dan Wilson - [email protected] wrote: > > Would it be possible to use a Work-Token as your unit of work? Then you > would be able to operate on the Work-Token, rather than the information > from the session/user. > > The Work-Token can be a UUID or whatever you like. Generate this when the > top-line entry point in the MG application is called. Process all your > units of work against the Work-Token (even if you have to translate that > into the user information for the database) and that way, even if the > submission happens twice, the long running requests will be shielded from > crossing streams. > > DW > > Brian G <javascript:> > Tuesday, February 12, 2013 3:22 PM > > I have some fairly lengthy processes that run one after another when > saving e-commerce transactions to the system. For maintainability, these > are spread across a few different events (which lets me error out and abort > in certain cases cleanly). However, I do want to protect against a > double-click or multiple submission from causing wonkiness (imagine the end > of the routine empties out an array as things are processed successfully > which leads to another running thread to wind up with an inconsistent array > length). > > Normally I'd wrap it in a cflock but this spans multiple MG events. Any > suggestions on another way to attack this? I don't really want to have one > monster controller event as I like the readability and the ability to reuse > individual broadcasts in other events. > > I suppose I could do some kind of a session flag and use that as a lock > but that would really just stop the extra requests rather than queue them. > Any other ideas? > > > Brian > > -- > -- > Model-Glue Sites: > Home Page: http://www.model-glue.com > Documentation: http://docs.model-glue.com > Bug Tracker: http://bugs.model-glue.com > Blog: http://www.model-glue.com/blog > > You received this message because you are subscribed to the Google > Groups "model-glue" group. > To post to this group, send email to [email protected]<javascript:> > To unsubscribe from this group, send email to > [email protected] <javascript:> > For more options, visit this group at > http://groups.google.com/group/model-glue?hl=en > --- > You received this message because you are subscribed to the Google Groups > "model-glue" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- -- Model-Glue Sites: Home Page: http://www.model-glue.com Documentation: http://docs.model-glue.com Bug Tracker: http://bugs.model-glue.com Blog: http://www.model-glue.com/blog You received this message because you are subscribed to the Google Groups "model-glue" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/model-glue?hl=en --- You received this message because you are subscribed to the Google Groups "model-glue" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
