Locking mach-ii properties (thread-safety)

[Po]

As I was exploring some of Mach-II's code on Github, I noticed that if I (hypothetically) happen to call the setProperty method from my app at some point during the request to set a property to "A" if someTempFlag is true, or to "B" if someTempFlag is false, I could then be causing race conditions when there are multiple concurrent requests since there is no locking implemented in the PropertyManager.cfc (nor in other component that calls the setProperty method that I could find).

Is there a reason for this, or is this never really an issue in your experience? (or maybe I am just completely misunderstanding something)

Thank you.

[Po]

Or is this something that was intended to be implemented as needed at the application level as opposed to being implemented at the framework level?

[Dave Shuck]

Properties are more intended to be static values for the most part and should never (I hate using "never", but I will stick with it in this case!) change per request or per user.  Think of them in the same way that you would application variables in a procedural application.  If you are looking to set temp values, I would recommend using eventArgs as they only span the life of the request.

@dshuck

--
To post to this group, send email to mach-ii-for...@googlegroups.com
For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en
 
SVN: http://svn.mach-ii.com/machii/
Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/

[Po]

Yes, I completely agree that application properties should (for the most part) not be set per request.  But I have had cases where I just needed to set an application wide property after the app had already started.  Even though this might not have been the best approach, at the time it was the one that proved to be the best solution.  So regardless of whether or not this was a poor choice, the fact is that the ability to do this still exists.

So I guess this question now is, if one ever needs to set an application property on request (one that is needed application wide, not just a temp value), should they make sure that they properly lock these setProperty calls if a race condition with a negative outcome can occur, or should this be something that is implemented at the framework level?

Thanks.

On Tuesday, 8 May 2012 12:52:51 UTC-4, Dave Shuck wrote:

Properties are more intended to be static values for the most part and should never (I hate using "never", but I will stick with it in this case!) change per request or per user.  Think of them in the same way that you would application variables in a procedural application.  If you are looking to set temp values, I would recommend using eventArgs as they only span the life of the request.

@dshuck

As I was exploring some of Mach-II's code on Github, I noticed that if I (hypothetically) happen to call the setProperty method from my app at some point during the request to set a property to "A" if someTempFlag is true, or to "B" if someTempFlag is false, I could then be causing race conditions when there are multiple concurrent requests since there is no locking implemented in the PropertyManager.cfc (nor in other component that calls the setProperty method that I could find).

Is there a reason for this, or is this never really an issue in your experience? (or maybe I am just completely misunderstanding something)

Thank you.

--
To post to this group, send email to mach-ii-for-coldfusion@googlegroups.com

[Matthew Woodward]

On Tue, May 8, 2012 at 10:03 AM, Po <ferm...@gmail.com> wrote:

So I guess this question now is, if one ever needs to set an application property on request (one that is needed application wide, not just a temp value), should they make sure that they properly lock these setProperty calls if a race condition with a negative outcome can occur, or should this be something that is implemented at the framework level?

You should lock that yourself since it's an edge case as far as the position of the framework is concerned.

--
Matthew Woodward
ma...@mattwoodward.com
http://blog.mattwoodward.com
identi.ca / Twitter: @mpwoodward

Please do not send me proprietary file formats such as Word, PowerPoint, etc. as attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

[Dave Shuck]

If you mean you just want to set something programatically as the application is being bootstrapped and keep it threadsafe, the configure() methods of plugins/listeners/filters are threadsafe.    I have been known to have plugins who's whole purpose of existing is to set programmatic properties at startup and only contain a configure() method.  In all my years of writing Mach-II applications, I have never really found a reason that I need to change properties at runtime after bootstrapping has completed, but this is probably more because of my narrow mindset that they are "static" variables in my applications.  Nothing would prevent you from implement locking yourself though.

@dshuck

--
To post to this group, send email to mach-ii-for...@googlegroups.com

[Po]

Thank you both for your replies.  I figured this was an edge case, but just wanted be sure.

On Tuesday, 8 May 2012 12:48:21 UTC-4, Po wrote: