Hi Reg, Cool, I think that is the way to go.
Thanks, Ruwan PS: please reply all so that the reply is copied to the user list to get a wider audience. On 10/8/10 5:49 PM, Reg Sherwood wrote: > Hi Ruwan > > Yes - my plan was to use the DB Report mediation on the inflow to > cache to a DB - the request. Then on the outflow, update the cache > value of the response again with the DB Report mediation. > > My other proxy interface contains an operation that the client will > use to access the cached value and returned the given chunked (1K) > units. This operations outflow will make a DB call to obtain the > cached value and locate the correct unit to return as per the clients > call. I figured I would need to use the Java mediation - but thought > I would ask the group to see if any other mediation would be more > applicable - thank you for confirming my approach. > > > > On Fri, Oct 8, 2010 at 2:50 AM, Ruwan Linton<[email protected]> wrote: >> Hi Reg, >> >> I guess you could use the existing DBReport mediator to store the message >> onto a database, if you need persistence for the cache. We have been >> implementing a cache on our complete carbon platform on the trunk, but this >> is not available on the 3.0 or 3.0.1 releases. >> >> So you will have to write bit of java code or some script to brake the >> message into 1K and the rest parts, and use the DBReport to store the >> message into the database. >> >> You could have another proxy with a different flow which contains a DBLookup >> mediator to fetch the cached part and deliver it back for the calls to that >> proxy. Also you might want to do some co-relation so that the client can ask >> for the specific message response. >> >> If you just need the in-memory cache, you may want to have a look at the >> caching mediator and use the same technic with a bit of Java code to >> accomplish this task. >> >> Thanks, >> Ruwan >> >> On 10/8/10 5:14 AM, Reg Sherwood wrote: >>> Hi >>> >>> I am new to WSO2. I have a meditaion setup as follows: >>> >>> Proxy >>> In Sequence: >>> Step 1: Receive client request >>> Step 2: Xform >>> Step 3: invoke end Point service >>> >>> Out Sequence: >>> Step 1: Response received from end point >>> Step 2: Xform >>> Step 3: cache response >>> Step 4: Send 1K of data for response >>> >>> My question is for the out sequence. If the payload to return to the >>> client is over 1K I need to cache it - that I can do via some form of >>> persistence. The client presumably will make additional requests for >>> the remaining data as it needs it. What would be the best approach >>> from a WSO2 ESB point of view to cache the data and return my initial >>> 1K data response to the client. I am thinking of using a java >>> mediation - but am wondering if other approaches would be better >>> suited to this usecase. >>> >>> All comments are appreciated. >>> >>> Thanks >>> >>> _______________________________________________ >>> Esb-java-user mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/esb-java-user >>> >> >> -- >> Ruwan Linton >> Software Architect& Product Manager, WSO2 ESB; http://wso2.org/esb >> WSO2 Inc.; http://wso2.com >> >> Lean . Enterprise . Middleware >> >> phone: +1 408 754 7388 ext 51789 >> email: [email protected]; cell: +94 77 341 3097 >> blog: http://blog.ruwan.org >> linkedin: http://www.linkedin.com/in/ruwanlinton >> tweet: http://twitter.com/ruwanlinton >> >> -- Ruwan Linton Software Architect& Product Manager, WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.com Lean . Enterprise . Middleware phone: +1 408 754 7388 ext 51789 email: [email protected]; cell: +94 77 341 3097 blog: http://blog.ruwan.org linkedin: http://www.linkedin.com/in/ruwanlinton tweet: http://twitter.com/ruwanlinton _______________________________________________ Esb-java-user mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/esb-java-user
