Post by Brent on Aug 9, 2009 16:52:07 GMT -5
Carl, I've been thinking about this for a while and considering ways to make it simple and safe.
There really needs to be a way to hold an object in memory, accessible to any thread, that holds prerendered content that can simply be rendered for each user.
The syntax I'm suggesting adds a new PERSIST keyword and adds functionality to the RENDER statement.
PERSIST strongly resembles the WAIT statement. It suspends the thread and places it in a pool, retaining its rendered state and a timestamp for when it entered the pool.
Other threads can call up the prerendered data using the RENDER statement with a string containing the object's project name instead of the normal object variable. If the required object is not in the pool, it is first loaded and executed the same way a RUN statement does.
This form of RENDER would also accept an optional second argument--a number of milliseconds. If the cached object is older than this, the object is re-runned and the new data takes the place of the old.
The cached project could still be executed with the RUN statement and methods called on its object. However, this would be a separate object from the PERSISTed object. It would not be committed to the pool until it executes a PERSIST.
The following pseudocode uses an external server for its data, but limits its requests to no more than once every 30 seconds.
There really needs to be a way to hold an object in memory, accessible to any thread, that holds prerendered content that can simply be rendered for each user.
The syntax I'm suggesting adds a new PERSIST keyword and adds functionality to the RENDER statement.
PERSIST strongly resembles the WAIT statement. It suspends the thread and places it in a pool, retaining its rendered state and a timestamp for when it entered the pool.
Other threads can call up the prerendered data using the RENDER statement with a string containing the object's project name instead of the normal object variable. If the required object is not in the pool, it is first loaded and executed the same way a RUN statement does.
This form of RENDER would also accept an optional second argument--a number of milliseconds. If the cached object is older than this, the object is re-runned and the new data takes the place of the old.
The cached project could still be executed with the RUN statement and methods called on its object. However, this would be a separate object from the PERSISTed object. It would not be committed to the pool until it executes a PERSIST.
The following pseudocode uses an external server for its data, but limits its requests to no more than once every 30 seconds.
' Project: livedata
' grab data off external source
xml$ = httpget$("http://some.com/data.xml")
' process data and render...
' put object into pool
persist' get live data no older than 30 secs
render "livedata", 30000
end