Friday's meeting

[Cantor, Scott]

> What I think I would like to understand is what the threading access rules
> are for various structure types.  For instance, the following would be nice,
> but is it accurate?
> 
> Attribute Filter, AttributeConnector & DataConnection definition:
>   - Single threaded access until #doInitialize() called
>   - Multiple threaded access from then on (but this is expected to be read
> only).

I actually think we should add an annotation for that case, @ThreadSafeAfterInit, along the lines of the @NonnullAfterInit I added. The storage API is like that, but it's marked @ThreadSafe right now.

> Attribute & Attribute Filter context:
>   - Single threaded access guaranteed by the environment.

Yes, maybe another annotation we should create.

> Logging:
>   - "Thread safe" meaning that same can Object be called by multiple threads
> and "the right thing will happen" - each method is Atomic, Consistent and
> mostly Isolated.

That's what @ThreadSafe should mean, yes.

> But what about web flows?

With some exceptions, we won't have much code that actually interacts with a flow itself. But they're threadsafe because the flow context is what tracks the state, I believe.

>  How are they serialized?

I don't think flows themselves are serialized, only the conversation state.

>  What about other  structures?   What do Services & reload do for us ?

That's a very open question. The goal was to address reloadability of systems using some kind of abstraction, but it isn't complete.

-- Scott