[rhetorical] Should AttributeResolver implement the Resolver interface ?

[Cantor, Scott]

On 11/10/13, 8:05 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>The other solution is to add a:
>
>doneWithServiceableComponent()
>
>to the ServiceableComponent interface and to wrap the call to
>getServiceableComponent in a try{}  and the doneWithServiceableComponent()
>in the finally{}.

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

When you use the component, you lock it, and when it gets updated there's
a write lock internally.

I realize this isn't how Java likes to do things, but there's a reason
they added lock interfaces; you need them to do mature software features.

>My technical concern lies in the fact that we absolutely *must* always
>call
>doneWithServiceableComponent(), otherwise destruction will not take place.
>It's easy to do this within the confines of a try/finally, but given the
>complexity of a webflow can we easily guarantee this?

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.

>I use reference counted subsystems (which is what this is) all the time to
>deal with exactly this sort of situation, but I'll admit that debugging
>reference count leaking can be a bear, and by their very nature bugs in
>these systems are not something you can easily test for.  Maybe Spring's
>lifecycle can help use here?  If the SWF is a bean which implements
>DisposableBean - does it suffice to call doneWithServiceableComponent() in
>the destroy() method?

I think we have destroy hooks in the Actions now we can use anyway,
without relying on the lifecycle bits.

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.

>My overall instinct is that if we are to implement safe reload then we
>need
>to go for the refcounted model.  But I am very leery of the pitfalls of
>adopting it.

It's worked very well in C++. And it's all hidden in one base class that
implements a simple Locking interface. Externally you just lock and
unlock. Internally, there's a read/write lock that allows the component to
update itself knowing nothing else is using it.

-- Scott