I have configured an adapter service to cache its results. The service returns a variety of data types including java.util.Date, java.lang.Boolean and java.lang.String. I’m encountering an error in which the cached results are initially stored as the appropriate data type, but are somehow eventually converting to all String data types. Once this “conversion” takes place all subsequent calls to the service return the correct cached DATA, however, the DATA TYPES are all String. If I reset the service cache and re-execute the service the correct data and data types is then cached and returned.
I use caching on a number of other adapter services, all of which return all string data types. I have no issues with any of these services.
Fred,
I believe there are some constraints on the datatypes that you can cache. Check for other threads in this forum on the subject and check the wM documentation on caching carefully. I’m fairly certain you can’t cache object datatypes.
Naturally, beware of the other “gotchas” associated with caching as well. These are well documented in this forum, but you probably already know those if you’ve used caching on other services. HTH.
I could not find any documentation indicating that objects cannot be cached, however, I did find the following note in the Developer’s Guide:
“Caching is only available for data that can be written to the repository server. Since nodes cannot be written to the repository, they cannot be cached.”
I’m not sure what “nodes” are, but I’m going to go ahead with the assumption that I shouldn’t be caching objects and re-work my solution such that I only cache string data types.
just to clarify nodes are nothing but(objects like bytes,java.lang.int,boolean,streams etc…)these are not cached objects.so ideal solution is convert them as strings and cache the stuff.
Hello,
An issue with cache, or other persistence of objects, is that you can not cache a stream to data (InputStream, FileInputStream, WM stream). So if you flush out your streams like storing to a String, Byte Array, Document. It only matters to eliminate the stream objects as those that are wrappers for primitives (Integer, Float, …), arrays of the like and Documents with fields of the like are safe to be persisted.
This is good to know if you use a BIZDOC as the contentpart is not local to the pipeline until you request it with getContentPart.
Caching on objects works fine as it does on Strings. Only thing is when caching a stream of any kind, it can only cache a reference and not the data. As the reference is nothing more than a memory address, this is also skipped in caching. Hence, after restoring a cached pipeline, no trace is found of the stream object.
As said by Yemi, if you need to persist a stream, flush it to a String or maybe StringBuffer (Object).