Die folgenden Methoden habe ich derzeit in einer abstrakten DAO-Klasse. Wenn es gleichzeitige Anrufe gibt, sind sie sicher wie sie sind oder sollte Synchronisation verwendet werden? Ich weiß, Synchronisation sollte verwendet werden, wenn es einen Verweis auf ein Attribut außerhalb des Bereichs einer Methode gibt, aber es ist mir unklar, wie Dinge mit einer externen Ressource behandelt werden sollen.
%Vor%Edit: Ich könnte diese Frage neu formulieren, um Informationen zum Schreiben von DAOs aufzunehmen, da es hier wichtig ist.
Ich stimme dieser Implementierung überhaupt nicht zu.
Erstens sollten DAOs ihre Verbindungsinformationen von den Diensten erhalten, die Arbeitseinheiten und Transaktionen besitzen.
Zweitens sehe ich keine Schnittstelle.
Drittens sehe ich keine Modell- oder Domänenobjekte.
Viertens sollten vorbereitete Aussagen nur Teil der internen Implementierung sein. Wenn sie aus Ihrem DAO herauskommen, machen Sie es falsch.
Fünftens, wenn eine vorbereitete Aussage aus dem Objekt herausgenommen wird, wird die Verantwortung dafür übernommen, sie zu schließen und weit weniger klar zu machen. Ihre DAO wird in kürzester Zeit einen Ressourcenverlust sterben.
Hier ist eine Schnittstelle für ein generisches DAO. Sie werden feststellen, dass es sich um alle CRUD-Operationen handelt, ohne dass Verbindungen oder Schnittstellen vom java.sql-Paket erwähnt werden:
%Vor% Damit kannst du einen langen Weg gehen. Es ist eine bessere Abstraktion. Der T ist Ihr Geschäftsobjekttyp und K ist der Primärschlüssel.
Wenn getCon() bei jedem Aufruf eine neue Connection zurückgibt oder eine ThreadLocal Verbindung zurückgibt, sind Sie sicher und Sie müssen synchronized
Wenn Sie dieselbe Verbindung an alle Benutzer zurücksenden, können Sie trotzdem in Bezug auf die Synchronisierung sparen, da in der Verbindung kein Status vorhanden ist, der geändert wird (in Ihrem aktuellen Code). Aber du solltest diese Übung vermeiden. Betrachten Sie stattdessen einen Verbindungspool.
Und ein paar Anmerkungen zu allgemeinen Designprinzipien. DAOs bilden eine separate Ebene. Jede Schicht besteht aus einem Grund, nicht aus Gründen, coole Namen zu haben. Die DAO-Schicht existiert, um zu abstrahieren, oder mit anderen Worten, den Datenbankzugriff von den Diensten, die die DAO-Objekte verwenden, auszublenden. Um es sich besser vorstellen zu können - die DAO muss so geschrieben sein, dass Sie, wenn Sie sich morgen von einem RDBMD-Speicher (via JDBC) zu einem XML-Speicher wechseln wollen, dies tun können, indem Sie only die DAO-Objekte und sonst nichts.
Die JDBC-Verbindungsklasse ist nicht garantiert threadsicher. Wenn Ihre Methode Database.getInstance (). GetCon () immer dieselbe Verbindung zurückgibt, treten Probleme auf. Wenn jedoch ein Pool verwendet wird, wird jeder Aufruf von getInstance (). GetCon () eine andere Verbindung zurückgeben.
Wenn Sie jedoch bei jedem Aufruf von getCon () eine andere Verbindung zurückgeben, funktioniert die Funktion getPreparedStatement () nicht, wenn zwei Prepared Statement-Aufrufe dieselbe Verbindung (und dieselbe Transaktion) verwenden sollen.
>Ich mag die JDBCTemplate-Klasse von Spring als Grundlage für meine DAO-Klassen.
Sie sollten nicht die gleiche Verbindung in jedem Thread verwenden. JDBC-Treiber sollten nicht Thread-sicher sein. Wenn Sie einen Thread-sicheren Code möchten, sollten Sie für jeden Thread eine Verbindung erstellen.
Der Rest Ihres Codes scheint sicher zu sein.
Schau dir an, wie Spring es macht, sie haben schon all diese Sachen herausgefunden und es gibt keine Notwendigkeit es neu zu erfinden. Sehen Sie sich den Petclinic-Beispielcode an, der mit der vollständigen Spring-Distribution gebündelt ist, oder lesen Sie das DAO-Kapitel des Bauer / King Hibernate-Buchs (für einen Nicht-Spring-Ansatz).
Definitiv sollte das DAO nicht dafür verantwortlich sein, die Datenbankverbindung zu erhalten, weil Sie mehrere DAO-Aufrufe in derselben Transaktion gruppieren wollen. Wie Spring es auch macht, gibt es eine Service-Schicht, die ihre Transaktions-Methoden in einen Interceptor verpackt, der die Verbindung aus der Datenquelle zieht und sie in eine threadlokale Variable stellt, in der die DAOs sie finden können.
Wenn Sie Ihre SQLException essen und null zurückgeben, ist das schlecht. Wie Duffymo hervorhebt, ist es sehr schlecht, PreparedStatement herumlaufen zu lassen, ohne sicher sein zu können, dass es jemals geschlossen wird. Außerdem sollte niemand mehr rohe JDBC verwenden, Ibatis oder spring-jdbc sind bessere Alternativen.
Tags und Links java synchronization jdbc dao