Anyone else have thoughts on this issue? It still seems like a key part of
understanding MINA, and I do think the Maarten's overall excellent and very
helpful tutorial is misleading as it stands on this point.
-Adam
On 6/23/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
On 6/23/07, Adam Fisk <[EMAIL PROTECTED]> wrote:
>
> Hi Maarten-
>
> Thanks for the link to that discussion thread. It seems like there's
> quite
> a bit of confusion on this point, though. The thread really didn't
reach
> a
> common consensus in my reading of it.
>
>
> > Indeed, I want thread-2 to see the changes made by thread-1.
> > But without synchronization, there is no such guarantee.
>
>
> Right, but the tutorial snippet says "MINA ensures that there will never
> be
> more than one thread simultaneously executing the decode() function for
> the
> same IoSession". For that to be true, there's gotta be some
> synchronization
> somewhere. I decided to dig into the code a little bit for the
> 1.1.0branch, and indeed ProtocolCodecFilter has the following:
>
> try
> {
> synchronized( decoderLock )
> {
> decoder.decode( session, in, decoderOut );
> }
> }
>
> With the code above, the changes made by thread-1 on the decoder *are
> guaranteed to be seen by thread-2*.
Indeed.
Now, I realize this is an
> implementation detail of 1.1.0, but the tutorial description above seems
> to
> be relying on that detail.
The fact that "no two threads will execute decode() for the same
IoSession"
is not an implementation detail, it's a guarantee of the framework.
The use of syncronized(decoderLock) is an implementation detail, but I
can't
immediately find
an alternative implementation that would cause visibility problems in your
decoder but still
guarantee that "no two threads will execute decode() for the same
IoSession"
so maybe that paragraph in the tutorial is not totally accurate.
Mina experts, what do you think about it ?
Still, I think it's worth reminding people about the danger of the
visibility problem in general.
So it seems like it should be totally fine to
> have a ProtocolCodecFactory that returns a new decoder on each
getDecoder
> call (effectively one decoder per session). I still don't see the
> disadvantage of doing this.
I guess you're right.
But the difference between one decoder per session or one decoderState per
session is small in my eyes.
It certainly seems less complicated that way!
>
> Thanks again for your patience Maarten. Seems like a key point we
should
> all be clear on, so that's why I'm trying to dig a little deeper here.
Right. Let's see what the rest thinks about it.
Maarten
-Adam
>
