Refresh Data in Screen
Wed, 2009-05-27 03:19 — felagari
Dear All,
I need to refresh data in my screen automatically without operator, when new data inserted in my database.
How do I get that ?
Thank's
- felagari's blog
- Login to post comments
Comments
You can't really push data
You can't really push data from the database to the user session. You can only have the user session periodically check to see if the data has changed.
The exception to this would be to use something like Sonic where a data access component could be responsible for all changes to a particular set of data and could maintain subscriptions for those who were interested in particular parts of the data and then could send messages to let subscribers know of changes. This is a good technique for commonly used data sets which are rarely updated, e.g., a table of states or provinces that is cached in the user session, but a message is sent should it ever change.
If your application is something like a dashboard presentation, this is a natural part of the application.
If you are talking about a simple maintenance screen, then you should consider how often the data is likely to change. If it is highly unlikely, then you would be better off implementing a form of optimistic locking and dealing with the updated record at the time of commit.
Using singleton class between db trigger and UI
Can we solve this problem of UI refresh on DB update by creating a singleton class( which have only single object in session)?
UI can register its handle inside this class and DB trigger can call class object whenever it gets updated. As there is single object of class in session which is using by both, trigger and UI, so both can interact well.
This is just my thought as I haven't used this approach practically.
I object to DB triggers in
I object to DB triggers in general and I would certainly never have one try to call an object in the local session ... sounds like asking for trouble.
There are really only three patterns here that come to mind.
One is polling to look for changes.
Another is to create a common datasource service, e.g., via Sonic, where a single point of contact manages all updates and thus is in a position to send notifications.
And the other is optimistic locking, i.e., to assume that 99.99% of the time, it is unlikely that the data being viewed is going to change, but to check when storing the data to see if it has.
Polling and the common data source are patterns which are appropriate for something like a dashboard where one is viewing status. Optimistic locking is the preferred pattern for table maintenance type situations.
'common datasource service' sounds good to apply
I don't know about Sonic, but 'Common datasource service' idea sounds good and it could be applied in customize manner.
I would not prefer polling where update is taking place rarely and we are hitting DB again and again just to check any update.
Optimistic locking also doesn't look good as if user1 is just viewing data and user2 is updating data then user1 will not be able to get updated data.
The common datasource
The common datasource approach is not a trivial implementation. For starters, you need to use something like Sonic to connect all the users to the source and they you have every user that wants a Customer record going to the Customer source instead of just getting the record directly. I should imagine the potential performance problems and bottlenecks should be apparent. This approach is best suited for something like a table of state codes which one downloads and caches and expects to remain unchanged in the session, but getting it in this way allows the source to broadcast a "table changed" event to signal everyone to refresh.
Optimistic locking might seem to be bothersome, but in reality it is the right solution in most cases. If you make short transaction scope, the likelihood of conflict is small ... how often would you expect two users to update the same Customer record at the same time? When there are no conflicts, it is seamless and invisible to the user. When you discover that a change has happened between the time you fetched the record and the time you are trying to put it back, you can do any one of several things including:
* abort the save, refresh the record, and push back to the user.
* merge the records on a field by field basis and only abort if both users have changed the same record.
* or just abort or just force the change.
The second is the most elegant as it means that one user can update the credit level and another user the telephone number and neither will be bothered by the other.