2010-12-16 13 views
0

Wir haben eine Webapp, wo jeder Client seine eigene db hat (ca. 700 im Moment).Verbindungen mit vielen Datenbanken

In SubSonic 2 mussten Sie jeden Anruf mit SharedDBConnectionScope umwickeln, um die richtige Verbindungszeichenfolge zu verwenden, andernfalls liefen Sie Gefahr, dass ein Thread oder Client Daten von einem anderen Thread oder Client abruft.

In SubSonic3 wird das noch benötigt? Muss ich die Anrufe wie in 2.x umschließen?

Es gibt einfache Möglichkeiten, die Datenbank jetzt zu wechseln, aber habe ich immer noch Threadprobleme oder kann ich den Anruf auf SharedDBConnectionScope abbrechen?

Antwort

0

SubSonic 3 erheblich verbessert die Art und Weise, einen Anbieter von Grund auf neu zu erstellen oder Weitergabe nur einen Namen und eine connectionsctring:

Einige Beispiele:

// Linq Templates: 
var db = new YourDB("connectionstring goes here", "System.Data.SqlClient"); 

// SimpleRepository without app.config 
IDataProvider provider = SubSonic.DataProviders.ProviderFactory.GetProvider(
    connectionString: "Server=localhost;Database=clientdb;Uid=root;", 
    providerName: "MySql.Data.MySqlClient" 
); 
IRepository repository = new SimpleRepository(provider, 
    SimpleRepositoryOptions.RunMigrations); 

Also im Grunde können Sie einen Anbieter erstellen oder jedes Mal Repository Ein Client verbindet und verwendet dies in Ihrer Klasse.

+0

Ich verstehe das. Ich setze die Verbindungszeichenfolge beim Erstellen der IQuerySurface (YourDB in Ihrem Beispiel) und das funktioniert gut. Aber in 2.x würden Threading-Probleme auftreten, Client a würde die Daten von clinet b sehen, wenn Sie nicht SharedDBConnectionScope verwenden. Ich frage mich nur, ob die gleichen Threading-Probleme vorhanden sind oder die Änderungen, wie Provider erstellt werden, helfen, das zu beheben. – JayGlynn