Thanks for getting back to me Maarten. Responses inline.
It's not because thread-1 has finished its decode call before thread-2 starts handling more data, that thread-2- will "see" the changes to the decoderState made by thread-1. This is a consequence of The Java Memory Model (do a google search on this, or try http://g.oswego.edu/dl/cpj/jmm.html)
Hmnn...I'm still not clear on this. Don't you want thread 2 to see changes made by thread 1? If thread 1 successfully sets the state in the decoder for an IoSession, and then thread 2 comes along with more data, you want thread 2 to use the state thread 1 set, right? If both thread-1 and thread 2 can be executing decode() simultaneously, it's a totally different story (and Doug Lea's concurrency nuances come into play), but your tutorial claims this is not the case.
I thought so too, until people on this mailing list told me about the disadvantages of that approach.
Interesting. Were those private messages or messages on the list? I'll have to do a little digging if they were on here. Thanks Maarten. -Adam
