Wie verwenden von JDBC in Java ee?

Ich bin in der Entwicklung in einer Java ee Umgebung (weblogic 12), und ein Teil von meinem code verwendet JDBC; Daher muss ich aqcuire einer JDBC-Verbindung vom application-server.

Ich weiß, es ist eine wirklich schlechte Methode in der Verwendung von JDBC in Java ee, aber das ist ein code, den ich nicht ändern kann (legacy).

Ich habe einen Weg gefunden, es zu tun, aber ich bin nicht sicher, es ist der richtige Weg:

@Resource(mappedName="mydsjndipath")
private DataSource ds;

public void foo() {
    Connection conn = ds.getConnection();
}

Die Frage ist, was mache ich mit der Verbindung am Ende?

Ich kann nicht wirklich commit/rollback, weil ich verwenden eine verteilte Transaktion. Aber sollte ich zumindest schließen?

Und die JTA-Transaktion wird immer die Wirkung der Verbindung (on commit/rollback)?

Oder gibt es vielleicht eine andere bessere Möglichkeit zur Verwendung von JDBC in Java ee? (Nein, der EntityManager nativen Abfragen nicht tun)

  • Warum wäre es eine schlechte Praxis zu verwenden JDBC in JEE?
  • Aus zwei Gründen: 1. Es ist wahrscheinlich besser, verwenden ORM (JPA). 2. Ich bin mir nicht sicher über diese, aber wenn Sie diese Schnittstelle nutzen, sind Sie nicht der Eröffnung einer neuen Verbindung, die nicht verwaltet werden von der application server?
  • Re 1. Warum ist es besser zu bedienen ist ORM? Wenn ich tun müssen, um eine bulk-update oder eine bestimmte Abfrage oder nicht brauchen, ein Objekt-Modell, warum sollte ich nicht nur die Verwendung von JDBC.
  • Re 2. Immer eine Verbindung von der Datenquelle bedeutet, dass Sie Sie bitten, die container/application-server für eine neue Verbindung, so erhalten Sie die Vorteile der container-verwaltete verbindungen. Auch, es muss nicht unbedingt eine neue Verbindung öffnen, kann er über die Verbindung, die der aktuellen Transaktion zugeordnet.
  • Am Ende des Tages, unter der Haube der ORM wird ziemlich viel tun, die gleiche Sache, es wird Sie bitten, eine Daten-Quelle für eine Verbindung auf, wenn es muss und wenn es fertig ist, es werde in der Nähe der Verbindung (die tatsächlich von hand die Verbindung wieder an den pool verwaltet der application-server)
  • 1. Ich finde nur drei Gründe für den Einsatz von JDBC in JEE; Leistung; nicht mit der Zeit zu lernen, ORM; und dass ein legacy-code, die JDBC verwendet. Wenn Sie eine Tabelle, die Sie nicht wollen, um anzeigen mit ORM, sondern nur zu Holen, Sie etwas genauer aus, können Sie mit der EntityManager-native queries. Wenn es das einzige Abfrage in Ihrer Anwendung dann würde ich bezweifeln Ihre Notwendigkeit für JEE. 2. Ich denke, es schafft eine neue Verbindung; ich habe aufgerufen 'getConnection' zweimal, und es gab mir zwei verschiedene verbindungen.
  • Ich denke eine Aussage wie "database access in der JEE-sollte immer durchgeführt werden, mit ORM" ist eine Verallgemeinerung, und ärger. Natürlich, es gibt viele Gründe für die Verwendung von ORM für spezifische Probleme. Für andere spezifische Probleme mit ORM ist overkill und wird das Ergebnis in reduzierte Wartbarkeit und reduziert die Leistung und Lösung, die schlechter ist als mit einem direkten JDBC. Nachdem alle, nur weil Sie haben einen Schraubendreher, verwenden Sie nicht es mit Nägel...
  • Ich habe nie gesagt, dass der Zugriff auf die DB sollte immer durchgeführt werden, mit ORM. Bei Verwendung von ORM in Ihrer Anwendung ist ein overkill, dann gibt es eine gute chance, mit JEE in Ihrer Anwendung ist ein overkill sowie.
  • Ich denke, wir werden nur Zustimmen, zu widersprechen. In meiner Sicht ist die Behauptung, dass "JDBC in JEE ist eine schlechte Praxis" bedeutet, dass es keinen Platz für Sie in der JEE-und aus meiner Sicht gibt es sehr viel ist und lassen einen application server verwalten die verbindungen mit JDBC, macht Sinn, und ist etwas, das passiert in mehr als der legacy-code.
  • Mögliche Duplikate von Schließen von JDBC-Verbindungen im Pool

InformationsquelleAutor wafwaf | 2012-03-19
Schreibe einen Kommentar