I understand that Servoy caches data at the application server level in order to facilitate data broadcasting - this is fine.
However, how long is this cache kept before ‘aging’ out ??
I just performed a test in my Servoy 4.0 application where I queried some records from table ‘X’ - there are 2 records being displayed.
I then updated 1 of these 2 records on the database directly using SQL*Plus - the update was committed on the database.
I re-queried the same data in my Servoy 4.0 application and the data that showed was the original data and not the updated data that I know is on the database.
How long would I have to wait before the cache of data on the application server aged out and I would see the updated data in my Servoy app???
Is this cache age controllable somehow ??
I realize I can try to find a way to use ‘flushAllClientsCache’ from within my application but that function works on a table-by-table basis - I have well over 100 tables in my application and am not sure how I would work that function in my app.
The important thing here is that it isn’t always the Servoy application that is updating my database - I have lots of other applications and processes that are adding/updating/deleting data.
If the users of my application are not going to see the latest and greatest data then I fear I will become the victim of a lynch mob
I tried something else and got some interesting results…
From my Servoy app I queried the same two records (from my previous post) from ‘X’ - I then used SQL*Plus to modify one of these values once again and committed the change on the database.
From my Servoy app I queried for the MODIFIED value (i.e. what I changed it to on the database in SQL*Plus).
Servoy found the record but what was displayed was the OLD value and not the MODIFIED value - hmmmmm…
When you modify records outside of Servoy there is no way that Servoy is aware of the changes and can not broadcast them as a result (makes sense).
As far as I know flushAllClientsCache is the most efficient one to do that.
You could use it just before your client is going to use one of more of the tables that could be affected outside of Servoy…
We have several batch processes that create/modify data all the time - our operation runs 24x7x365
Sounds like the only way I’m going to be sure that my Servoy applications are seeing current data is to write some kind of headless client that will refresh the cache of ALL the tables that my Servoy applications access.
Sounds like the only way I’m going to be sure that my Servoy applications are seeing current data is to write some kind of headless client that will refresh the cache of ALL the tables that my Servoy applications access.
It seems to me that you will risk non-up-to-date data as well this way or would you call a method through that client to flush cache after each change?
If so I would consider setting up a batch processor for that but maybe there are ‘smarter’ ways to handle this.
markhooper:
However, how long is this cache kept before ‘aging’ out ?
It does does not, unless flushed via rawSQL plugin, adminpage flush or refresh is called from within client (as pointed out already)
markhooper:
We have several batch processes that create/modify data all the time - our operation runs 24x7x365
If those are not Servoy batch processors Servoy clients will not know.
How do you in your current situation make sure the data is seen in consitent way by any process reading from the database at any time? are you starting serializable transactions before any read/select?
Our current application server (Oracle Forms/Reports) doesn’t cache the data - rather, the Oracle database server itself looks after caching.
In the event that someone is looking at ‘old’ data in an application and then attempts to save their changes the form will check ‘row_changed_date’ values and realize that the record has changed since the user queried it originally and must re-query it.
Having the Servoy application server cache the data is a new thing for us. We just have to learn how to leverage it - but it sounds like we are going to have to create the headless client that periodically flushes the cache. Some tables will require frequent cache flushes while others will require less frequent flushes.
An example where this presents a ‘problem’ is the case of ‘row_changed_date’ - this column (on every table in our database) is stamped by a database trigger (and NOT the applications) for consistency sake (i.e. client clocks can be way wrong). When I save a record on my Servoy form the ‘row_changed_date’ doesn’t change (even though the database trigger set it during the actual update). I tried to set the column from within Servoy to ‘database managed’ and then ‘modification server datetime’ but it made no difference - the ‘row_changed_date’ on my form didn’t change when the record was saved. The ‘row_changed_date’ was definitely changed on the record in the database however (I confirmed via SQL*Plus).
I’m showing the ‘row_changed_date’ on the form because the clients want to see that information. Having it not change even though the client just saved will require an explanation from me and I’m not sure what to tell them
You can refresh an individual record from the database if you know it’s just been changed
Try this at the end of your save method or on-record-edit-stop event and see if this refreshes the value populated by your triggered:
This can be expensive because it operates on all clients. One way to optimize is to invoke this only after an external process has run.
You can setup a headless client, and using the headless API, invoke via a simple web service from your other apps to flush whatever tables were modified at the moment they’re modified.
Less optimal, but easier to program would be to use the scheduler plug-in and guesstimate when each table might need to be flushed.
Still, you could parameterize it, so that each tables refresh time is easy to configure and tweek.