I’m working my way through the list of questions posed during the Eclipse RCP webinar.
One listener asked about a dozen questions (and I’m hoping to get to them all, really), including this one:
When talking about the user working offline with the intelligence in the application – where and how should the data be cached? What mechanism would you suggest for synchronisation and beyond that for handling resolutions?
Golly, that’s a tough one. For this one, I have to put my old consultant hat back on… the answer is “it depends”. Unfortuately, this really is the answer. It’s difficult to provide one single right answer for any situation, but there are several options you might consider (and which one is right depends on what kinds of things you need your application to do).
You could cache your application information in EMF-generated objects. Since EMF provides a pretty handy mechanism for writing out an object graph, this may indeed be a really good fit if your application is actually written to manipulate objects (and not just read and write gobs of data from a database). In this case, the model is pretty simple: you load your data from whatever data store you get data from into your EMF object model; your application can them merrily pound away on the objects (perhaps add, remove, or change a few of them) before either (a) writing them back to the data store, or (b) storing them in a file on the local disk. With this option, synchonization with the original data store is a matter of reconstructing the objects from the file (which EMF does for you) and then doing the necessary queries to write the data back.
Another possibility is to use a Java-based local database like Derby. You could write data that your client needs to the local database and access it from there using the same (or similar) mechanism that you use to access the main database. Synchronization is a matter of reading data from the local database and writing it back to the remote one. For this solution, I’m assuming that the RCP application directly accesses the remote database rather than working through an application server.
In both cases, knowing what actually needs to be written back to the original data store is an interesting challenge. In either case, you’ll probably need to have some mechanism for keeping track of what’s changed so you can optimize your writes. I don’t think that Derby has any ability to synchronize a local database with a remote one, but there may be other products out there that can do this sort of thing.
I like the EMF option for two big reasons. First, I like objects and I’m probably going to read my data into an object model anyway; EMF is a good way to represent an object model and provides all the functionality I need to store that object in a file. Second, with EMF, it’s pretty easy for me to develop a mechanism that can keep track of exactly what changes in my object model so I can know exactly what needs to be written back to my remote data store. I’m pretty sure that SDO may offer even more, but I haven’t had a chance to really look hard at SDO yet.
Of course, as I stated earlier, it all depends. The EMF route feels right when I need to retain a relatively small amount of data locally. I probably wouldn’t use it if I needed to have access to my entire database or a significant subset of it: in that case, I’d probably look harder for a good database replication story.
Our intrepid leader Mike recently asked me to build an example of how all this stuff might actually work. So keep your eyes on my blog… it’ll all be so very exciting.
