Skip to main content
Archived

Cache Database Reader data

  • March 6, 2015
  • 2 replies
  • 49 views

fmelizard
Safer
Forum|alt.badge.img+22
Some Readers are used to access data that may be static (doesn't change at all or changes rarely) or during development/debugging one should consider not hitting a DB server frequently with the same query. So all or some Readers should have an option to mark it as 'static', and some caching mechanism would be implemented.
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

2 replies

whit
Contributor
Forum|alt.badge.img+3
  • Contributor
  • March 6, 2015
This idea can also fall under a general frontend service to the fme server datastreaming service. So that basically a cacheing service (or reverse proxy) can be put in front of a data streaming service. Not unlike fme servers kmlnetworklink service where it just calls the fmedatastreaming service if needed.

bo
Contributor
Forum|alt.badge.img+10
  • Contributor
  • November 27, 2016

Another case for cached reader -

I have a workspace that calls a custom transformer more than 50 times. If I feed the "static" data sources from the workspace to each instance of the custom transformers through input ports, the workspace looks very busy and is difficult to manage due to so many extra connection links from the "static" data sources to 50+ instances of custom transformers.

The cleaner and OOP approach is to put the "static" data sources inside the custom transformer; however, without cached reader or shared memory data access support, I am afraid we incur heavy disk read cost.