Adobe Flex with BlazeDS - How to maintain synchronized data between client and server database?

I’m working on an Adobe Flex app that uses BlazeDS with AMF for server communication. I’m struggling with how to keep my client-side data synchronized with the database on the server side.

The issue is different from regular web apps where pages reload and grab fresh data each time. In Flex, I tend to load lots of data upfront and share it between different components and views. This means the data gets refreshed less frequently and can become outdated, which causes issues when users try to save changes.

I’m considering a few approaches:

  1. Treat the Flex app like a traditional web application and fetch fresh data whenever switching between views
  2. Accept that data might be stale sometimes and handle conflicts when they happen during save operations
  3. Look for alternative solutions

What would you recommend as the most effective approach? I should mention that using LiveCycle RTMP for real-time data channels isn’t possible in my situation.

definitely go with option 2 - embrace the staleness and build solid conflict handling. I’ve tried constant refresh before and it destroys performance. Users hate seeing loading spinners everywhere. Optimistic locking works great here. Just version your records and handle merge conflicts gracefully when they happen. Data conflicts are pretty rare unless you’ve got tons of users hitting the same records at once.

Had the same issue with a BlazeDS financial app where stale data was a huge problem. I went with a hybrid caching approach using timestamps. Each data object gets a server timestamp, and before any write, I do a quick timestamp check against the server. If the data’s stale, I only refresh what’s actually changed instead of reloading everything. For reads, I set up different cache expiration times based on how often each data type actually changes. Cut server calls by about 70% without breaking data integrity. The real game-changer was adding a simple conflict resolution UI. When there’s a conflict, users see both the current data and what they’re trying to change, then decide how to handle it instead of getting silent failures or overwrites.

what kind of data are you dealing with? does it change a lot or stay pretty static? I’ve had better luck mixing strategies instead of using just one - cache reference data for longer periods but refresh transactional data more frequently. have you considered a dirty flag system to track what actually needs syncing?