Has anybody successfully used Stateless and Caching features of a service? I had some difficulties earlier where, a cached service also cached the pipeline and overwrote my pipeline with those values. I am yet to try it in 4.6.

I’ve used stateless settings to avoid creating a session (most times it’s not needed). Any particular question regarding stateless services?

Still don’t quite understand when to use, when not to use. Any examples?

When you create a service that will be externally invokable (ie. one that you will expose to clients) make it stateless unless you store data in the session for later use (by a subsequent request from the same client). You don’t need the overhead of all these sessions lying around for just one request. The wm.tn:receive service (TradingNetworks) is stateless for example.

For caching, the documentation states that “When the server receives subsequent requests for a service with the same set of input values, it returns the cached result to the client rather than invoking the service again.” The only way a cached pipeline would be used is if you provide the same input values. So don’t use caching if the service will provide different output for the same input (flows that get the date/time for example). Here’s another quote from the developer’s guide "If a service retrieves data from a data source that is updated frequently, the cached results can become outdated. Do not cache services that retrieve information from sources that are updated in real-time or near real-time, such as stock quote systems or transactional databases. "

So my philosophy is generally NOT to use caching since most services retrieve dynamic data from a database that gets updated from other sources (even with the same input values).

Will

Thanks Will.
How about making some internal services stateless, for example WmMarketConnect sendEnvelope service?

I had an interesting time experimenting with the caching switch on/off and experienced the same issue of the cache overwriting the pipeline. In fact, many times, the pipeline would contain old data that would skew or render the current transaction useless.

I worked around this by storing data in the repository and extracting the values I needed later by using a key still present in the pipeline. This cut down on the size of the vectors that are created between flow steps by only keeping the data needed at that time and dropping the data that is not needed.

Generally speaking, Stateless is the best way to go because it forces the flow to handle transactions in an atomic manner and doesn’t leave behind any objects that could corrupt other transactions later.

Opinions are running amok!

Ray

> Thanks Will.
> How about making some internal services stateless, for
> example WmMarketConnect sendEnvelope service?

Hi PU - don’t have much input for the advantages of making internal services stateless, but just wanted to pipe in to say that, with WM very weak in version and config management, its good practise not to touch the internal Wm-provided packages unless there is good reason to.

I concur with what Will says - you generally must make externally-invokable services stateless. I’ve had a session-expiry problem once occur between 2 WM boxes. It was fixed by making the invoked service stateless. This is the thread:
[url=“wmusers.com”]wmusers.com

Thanks all for sharing your experiences