Mutliple Contexts? Good or Bad practice?

I have a service that runs on our server, it's job is to connect to multiple databases in other computers on the network, and sync the data back to a centralised database. 

There could be tens of computers it needs to connect to, but unlikely to be more than 20.   Each connection is maganed using a Quartz timer.  Finally, we only know the computers we need to connect to at run time, we do not know them at design time.

My questions is, based on the inner workings of LS, is it better to instantiate a seperate class with a private context for each connection, or is it better to create a single static context and simply change the connectionstring, prior to each connection?

Thanks for your advice,

You should use a separate LightSpeedContext for each database/server you need to talk to.

There are a number of reasons.

One is that a unit of work refers to its context throughout its lifetime.  If you were to modify the context while the unit of work was using it, things could get very messy.

Another is that identity allocation happens at the context level.  Suppose you were using KeyTable allocation.  The first time LightSpeed needs to allocate an ID, the context points to Server A, whose KeyTable is positioned at 1000.  So LightSpeed starts allocating IDs: 1000, 1001, 1002.  Then you change the connection string to point to Server B.  LightSpeed allocates ID 1003, which would have been safe on Server A, but happens already to be in use on Server B.  Whereas if you used different contexts then the Server A and Server B sequences would be independent and therefore safe.

There are probably more but hopefully that's enough to put you off!

(Note you do not need to create a new context per database connection (IDbConnection) -- that's what the UOW is for -- only one context per database instance if you see what I mean -- one context per connection string.)