Flex - best strategy for keeping client data in synch with backend database?

Question

In an Adobe flex applicaiton using BlazeDS AMF remoting, what is the best stategy for keeping the local data fresh and in synch with the backend database?

In a typical web application, web pages refresh the view each time they are loaded, so the data in the view is never too old.

In a Flex application, there is the tempation to load more data up-front to be shared across tabs, panels, etc. This data is typically refreshed from the backend less often, so there is a greater chance of it being stale - leading to problems when saving, etc.

So, what's the best way to overcome this problem?

a. build the Flex application as if it was a web app - reload the backend data on every possible view change

b. ignore the problem and just deal with stale data issues when they occur (at the risk of annoying users who are more likely to be working with stale data)

c. something else

In my case, keeping the data channel open via LiveCycle RTMP is not an option.

Answer 1

In the past I have gone with choice "a". If you were using Remote Objects you could setup some cache-style logic to keep them in sync on the remote end.

Sam

Answer 2

Can't you use RTMP over HTTP (HTTP Polling)? That way you can still use RTMP, and although it is much slower than real RTMP you can still braodcast updates this way.

We have an app that uses RTMP to signal inserts, updates and deletes by simply broadcasting RTMP messages containing the Table/PrimaryKey pair, leaving the app to automatically update it's data. We do this over Http using RTMP.

Answer 3

If you can't use the messaging protocol in BlazeDS, then I would have to agree that you should do RTMP polling over HTTP. The data is compressed when using RTMP in AMF which helps speed things up so the client is waiting long between updates. This would also allow you to later scale up to the push methods if the product's customer decides to pay up for the extra hardware and licenses.

Answer 4

a. Consider optimizing back-end changes through a proxy that does its own notification or poling: it knows if any of the data is dirty, and will quick-return (a la a 304) if not.

b. Often, users look more than they touch. Consider one level of refresh for looking and another when they start and continue to edit.

Look at BuzzWord: it locks on edit, but also automatically saves and unlocks frequently.

Cheers

Answer 5

You don't need Livecycle and RTMP in order to have a notification mechanism, you can do it with the channels from BlazeDS and use a streaming/long polling strategy

Answer 6

I found this article about synchronization:

http://www.databasejournal.com/features/sybase/article.php/3769756/The-Missing-Sync.htm

It doesn't go into technical details but you can guess what kind of coding will implement this strategies.

I also don't have fancy notifications from my server so I need synchronization strategies.

For instance I have a list of companies in my modelLocator. It doesn't change really often, it's not big enough to consider pagination, I don't want to reload it all (removeAll()) on each user action but yet I don't want my application to crash or UPDATE corrupt data in case it has been UPDATED or DELETED from another instance of the application.

What I do now is saving in a SESSION the SELECT datetime. When I come back for refreshing the data I SELECT WHERE last_modified>$SESSION['lastLoad']

This way I get only rows modified after I loaded the data (most of the time 0 rows).

Obviously you need to UPDATE last_modified on each INSERT and UPDATE.

For DELETE it's more tricky. As the guy point out in his article: "How can we send up a record that no longer exists"

You need to tell flex which item it should delete (say by ID) so you cannot really DELETE on DELETE :)

When a user delete a company you do an UPDATE instead: deleted=1 Then on refresh companies, for row where deleted=1 you just send back the ID to flex so that it makes sure this company isn't in the model anymore.

Last but not the least, you need to write a function that clean rows where deleted=1 and last_modified is older than ... 3days or whatever you think suits your needs.

The good thing is that if a user delete a row by mistake it's still in the database and you can save it from real delete within 3days.