[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Rod Widdowson]

> Almost. What you need is a locking interface, which is what I did in C++.

Yea, locking is what V2 uses.   My problem with locks is that unless you
code them carefully they end up turning localized hangs or stalls into a
systemwide ones.   But implemented carefully they are functionally
equivalent of a refcount.  Further, although I'd claim that the V2
implementation is not as carefully done as I'd like we haven't had any
reports of the misbehavior which I know this design could engender so I'm
probably over-reacting.

> And while you can reference count, I wouldn't advise it, I'd let a Lock do
> that for you. Shared locks already do this internally.

I'd disagree with you.  But I'm not going to die in a ditch for it - it’s
just a detail.   After all dropping a shared lock or dropping a refcount are
just implementations behind the doneWithServiceableComponent() call..  I
probably let myself be overly influenced by experiences which are not
necessarily relevant in this sphere...

> It's not the flow doing it, it's the actions. You just have to lock at the
> start and release the lock. You could even implement Closeable and do try
> with resources.

My concern is that there are several actions (e.g. ResolveAttributes,
EncodeAttributes) which all run from the same configuration.    If we want
to guarantee that all actions in the same webflow run from the same
configuration your lock (or pin) has to span the call to both actions (or
invent some other mechanism).  If we can live with the potential disjunction
it's not an issue of course.

/Rod