This project is read-only.

Occasionally connected scenario

Aug 27, 2010 at 11:22 AM

Is this framework good for handling occasionally connected scenario. So if I wanted the user to be able to use a local database in absence of a live connection to the services and use the live services when available - would that be something we could handle / address using this framework?

Aug 27, 2010 at 7:11 PM
Edited Aug 31, 2010 at 10:58 AM

Hi again.

These online-offline scenarios have a really high complexity: we had to deal with one project with this specificiation some years ago (with a very early version of our framework) and I can assure these were not an easy job.

The first quest you have to deal with is to identify the functionality available when online and the one present when offline. For all data needed by the client but not available on offline, you will have to conceive some kind of local cache, to be able to retrieve it when disconnected (maybe a local db, but taking present the considerations further).

The second (and bigger) problem is to provide the functionality to store all the data locally on the client, and, when it becomes connected, synchronize it with the server. That's on an ideal scenario where you just have to sync the data from one client to a central repository. If the requisites say that the same data can be modified by more than one client -or in the client and in the server separately-, then the design becomes even more a real nightmare.

Signum Framework does not provide a constructed way to manage this kind of scenario, but you can benefit from some of its advantages to speed up your development.

As first approach, beware of the idus march... er, no, that was not here, well, you have to beware of using a local database to storage the data until the synchronization with the server. If you mount a database in the client and save your entities there, all the IDs will be related to that db.

And what does it mean? Take a look: When you save locally your first object (i.e. myPerson), the system will asign the ID 1. Later, you connect with the server, and send it the object. You can't send myPerson with the local ID, because the server, seeing it as not new, will try to update instead of insert, throwing an exception. So you will have to develop some kind of adapter that, taking a locally-saved myPerson, generates a new myPerson (with all the properies except the IDs and timestamps) to send it to the server.

One step more, let's suppose there were another myPerson saved before (maybe by other client that synchronized previosuly to our). In that case, the myPerson we're sending will asume the ID 2 in the server, so now we have a conflict beteween the server and client IDs. If, for any reason, the clients need to retrieve a myPerson to store it locally, a mapping between local and server IDs is needed to maintain synchrony, because the local db can't either save the myPerson with the server's ID. One solution could be using GUID as identifier/foreign key (as they are unique can be used in both sides), but Signum Framework does not use it, so you'd have to implement it for your entities.

Other consideration we should have in main is the concurrency editing data locally. If the client have to retrieve the myPerson from the server, edit it and later send it again to the server to update it, what happens if, meanwhile, other client retrieved, edited and saved it yet? In a "first winner" scenario we'd have no problem, because the Signum Framework itself would not allow the last client to update (as there's no timestamp correspondence, the concurrency validation does not allow it). In a "merge all data" scenario, ask for tons of pizza and coffee because you have a lot of sleepless nights ahead of you.

So, where are the good news? Well, if you choose the local-database option, you can use Signum Framework to perform all the save/retrieve operations, saving time and effort (and believe me, you'll need it planning and developing the synchronization system). 

On the other side, if you choose a not-local-database scenario, the main thing that Signum Framework offers to you is the Serializable attribute of the entities. It means that any entity can be serialized locally, so when offline you can create it, store it serialiazed, retrieve deserializing, edit all the properties in memory, store it serialized again... and, at last, when go online deserialize it and send it to the server to save it in the db. The cons are the lack of quering and navigation between local entities, as all that functionality uses db to perform searching and retrieving.

Maybe i'm jumping the gun with all the previous considerations ("hey, what a so obvious ideas from this guy for a helpless solution"), but these are real problems to take in mind, and I hope it was helpful.

Aug 27, 2010 at 8:35 PM

We were hoping to build the application in conjunction with the MS-sync services and use that for the purpose of synchronizing the data. To add some answers to the points raised by you:

1. Our users will work in either connected or disconnected situation at any time. They will not move from disconnected to connected scenario before finishing the synchronization.

2. They will have a manual synchronization button that will first synchronize the data and then switch them to the online mode.

3. Updates will all be winner first scenarios - merge all data will be considered.


How do you envision this kind of the thing working with Signum Framework? Like I am not able to figure how to setup multiple data sources for the application so it can work with the local cache when offline and with the live services when online?

Aug 30, 2010 at 9:45 AM

I'm not sure how MS-Synch works, but: 

* In order to change the datSource just create a different Connection object and use ConnectionScope class, explained here http://signumframework.com/Connection.ashx

* Anyway, I suppose the local connectionString is used when offline, and a service reference when online. There's no automatic way to abstract away this two modes, since some capabilities (LINQ queries for example) are directly available only if u have access to the database.

I hope it helps,

Kind regards,

Olmo