Hi All
Is there a way for caching in memory a web service data and response ?
And if exists a nice way for managing data in memory.
Actually, while creating a policy from the portal, we have 8 to 9 webpages and for each webpage we have different different web service call, which hits DB, creates few DB transactions and returns the response. But because of this process we are facing some serious performance issues at DB levels.
I am looking something related to the cache memory or memory pointer which will keep all the data in memory and finally in a single shot will update the DB tables.
Well, there could be various ways, one way is looking at the HTTP level (see: developers.google.com/.../http-caching. Another way can be done in OE. Assuming your data is not changing every second (then you *must* hit the db every time), the response should be a function of the request. So: f(request) = response. If you somehow concatenate the request parameters and hash this you have a unique number (the hash) representing the request parameters. Based on the hash you can cache your data either in memory of on disk (the latter makes it possible to share the result among all AppServer agents). hashing can be done with the message-digest function. On the every request you hash the request parameters, check if the hash is in the cache etc...
and use interfaces and dependency injection so you can easily switch from a in-memory cache to a database cache or whatever you come with. (just an advice)
Caching otherwise dynamic content is most of the time not a good idea but depending on the specific content of one page you might decide to let the browser cache the content for one hour/day or more - there are http headers for that (see cache-control on Bronco’s link).
ah yes, have that modelled as business entities that uses a data access layer and then be sure you group them together in business tasks for a proper OERA sandwich ;)
[quote user="marian.edu"]each agent will have it’s own cache hash-table so be prepare to throw in some extra RAM
[/quote]
I would say: use PASOE and if Progress is kind enough to implement define universal shared temp-table
then the RAM issue is solved :-)
But you're right, writing a good cache isn't easy (it is fun though).
Actually the old programs are designed in such a way where they are unnecessary hitting DB & creating records in the tables in each web service call even before the actual policy creation just to show some information on the next page. For example, on the 1st page itself when we put customer information and proceed for the next page, data gets created in the tables such as account information and many more just to show information on the next page and just like this for every next page we have web service calls and DB hits till the last page which is causing the issues.
These DB hits are not only for the couple of table data population but to read couple of master tables as well. So we are planning to restructure the progress code but it is not easy for us as of now and so we are looking for the memory related concept in progress programming ( Not HTTP level ) where we can skip these DB hits in between.
if you are operating over multiple web pages, gathering data, you could maybe look at the web storage api and cache it in the browser (see developer.mozilla.org/.../Using_the_Web_Storage_API )
there are a few javascript wrapper libs out there too providing fall back for older browsers etc.