Mike, Brian - It depends on the situation, but generally, it is important to have top-level document receive services stateless.
There has been some good advice on this thread, particurly from Rob. My understanding below is based on 4.6, but it should be the same for 6.1.
Lets say you create a HTTP receive service and keep it’s default state setting (i.e. keep it a ‘stateful’ service). When the service is invoked by an external HTTP client, IS will try and establish a “long-term” session (as opposed to a short-term session that terminates immediately after the invoke – as Fred pointed out).
Now, the HTTP client may or may not use this cookie - if it resends the cookie, it reuses an existing session on the server. If not, each of it’s subsequent HTTP requests creates a new ‘long-term’ session on the server (which will eventually time-out). These sessions consume server resources - furthermore on 4.6, I have seen the server ‘pause’ when a huge number of sessions time-out all at once.
Hence, if the service performs a unitary function, it is best practise to keep the top level external receive service stateless. For eg: wm.tn:receive is marked stateless
The stateful setting on lower level services does not matter.
Most simple HTTP clients do NOT resend the cookie – such clients cannot exploit server state even if the service is stateful. The webMethods HTTP client does resend cookie by default (there is a server.cnf setting you can use to turn this off). Ironically, this feature, in conjunction with an IS 4.6 “session timeout” bug caused major problems only when webMethods clients would connect to webMethods servers (non-WM to WM was OK!) . The bug was fixed by 4.6 IS FIX 125 if I recall correctly.