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)
> 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)
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.
On Tue, May 8, 2012 at 11:48 AM, Po <fermar...@gmail.com> wrote:
> 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)
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?
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)
On Tue, May 8, 2012 at 10:03 AM, Po <fermar...@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.
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.
On Tue, May 8, 2012 at 12:03 PM, Po <fermar...@gmail.com> wrote:
> 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)
> 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)
