I've got a quick question for Maarten and anyone else on the snippet on threads and IoSession attributes from tutorial on ProtocolCodecFilter. The tutorial reads as follows:
--- start quote -- "We store the state of the decoding process in a session attribute. It would also be possible to store this state in the Decoder object itself but this has several disadvantages: every IoSession would need its own Decoder instance MINA ensures that there will never be more than one thread simultaneously executing the decode() function for the same IoSession, but it does not guarantee that it will always be the same thread. Suppose the first piece of data is handled by thread-1 who decides it cannot yet decode, when the next piece of data arrives, it could be handled by another thread. To avoid visibility problems, you must properly synchronize access to this decoder state (IoSession attributes are stored in a ConcurrentHashMap, so they are automatically visible to other threads)." -- end quote -- If only one thread executes decode() at a time, though, doesn't that mean the "thread-1" will have already finished its decode() call when more data arrives and the next thread tries to handle it? If so, I would think any complicated synchronization issues would not arise because anything that happens within the decode() method is only happening on one thread at a time. I ask because it seems like each IoSession having its own decoder instance with its own internal state is a pretty good idea! Am I missing something? Thanks a lot. -Adam
