cflow implemented with ThreadLocal

[bill.burke]

In attending AOSD, I found that others implement CFLOW differently than I have. I use new Throwable().getStackTrace and parse the stack. This is slow as balls. The way others use it is that they increment a ThreadLocal counter at the execution point of a element in the cflow expression.

The debate is, yes, the ThreadLocal approach is a much much much faster implementation of cflow, but if cflow check is a rare occurance, then you have slowed down execution joinpoints signficantly.

I guess the answer is to do either or and through configuration turn on/off this optimization.

Bill

[rythos]

Yeah, that's my fault. Sorry man :). When I wrote it myself it seemed like the correct way to do it, but Gregor set me straight when I showed him my code.

[bill.burke]

No, not your fault, it was the easiest way to implement it and I didn't use your code. Besides, it is BETTER in some situations when the CFLOW trigger is a rare case. We have some of these usecases in our application server where doing it the ThreadLocal way would add too much overhead for a CFLOW that was rarely triggered.

Bill

[rythos]

Oh thank goodness! I thought I had just unintentionally alienated another person in the field I'd like to end up in ;)