Hi.
I would like to know what are the advantages of setting the stateless property to true in the integration server services?
Is this recommended?
It is recommended to keep top-level services as stateless always, unless it is called by clients for whom you want to maintain sessions (example: same client calling your service very often).
Setting stateless property to false will cause IS to send back cookies, maintain sessions in the IS, which adds up into heap usage and additional overhead in managing the sessions. setting it to true will avoid these tasks, however, auth happens everytime user attempts to connect.
Unless you want session to be maintained, set stateless property to true.
-Jay
This is helpful, thanks. I’d love to make this the thread where we clear up as many aspects of this as possible, as the docs could be clearer regarding which situations stateless is for.
For example:
- If I’m using IS for web services to populate a CAF frontend, and I’m using Basic Authentication, will stateless help because it’s only storing one set of credentials for a huge number of web service calls?
- By the same token (hah), if I’m using Hybrid authentication (recommended, I believe), so the MWS login credentials are passed to IS, does stateless still make sense, given that now everyone is calling with different credentials?
- What about non-top level services? Should they always be stateless? Why/why not?
- Does stateless only apply to HTTP calls, or will a remote invoke/subscription service also cache credentials? Does it apply to web service calls, or are they handled differently as there’s a connector in between?
- The documentation cites XA transactions as being a reason for turning stateless off. How does this work? Doesn’t the transaction get passed through if stateless is on? If it does, then why do the docs mention this?
Probably more, but if anyone knows the answer to any of those, please share 