通過tomcat上下文文件和spring context聲明數據源之間的區別

聲明DataSourceMETA-IF/context.xml文件並使用JNDI查找（方法1）從spring bean中獲取它或者直接通過Spring聲明DataSource （方法2），如：通過tomcat上下文文件和spring context聲明數據源之間的區別

@Bean(destroyMethod = "close") 
DataSource dataSource(Environment env) { 
    HikariConfig dataSourceConfig = new HikariConfig(); 
    dataSourceConfig.setDriverClassName(env.getRequiredProperty(PROPERTY_NAME_DB_DRIVER_CLASS)); 
    dataSourceConfig.setJdbcUrl(env.getRequiredProperty(PROPERTY_NAME_DB_URL)); 
    dataSourceConfig.setUsername(env.getRequiredProperty(PROPERTY_NAME_DB_USER)); 
    dataSourceConfig.setPassword(env.getRequiredProperty(PROPERTY_NAME_DB_PASSWORD)); 

    return new HikariDataSource(dataSourceConfig); 
}

我認爲第二種方法比較好，因爲是不依賴於一個specefic服務器，這意味着如果我們使用第一種方法，有一天遷移到另一臺服務器，我們必須適應的strategie第二個服務器中的上下文文件（不是正確的？）。

由於

來源

2016-03-17 Sayros

請問這個涉及到標籤的「表演」？ –

Hello @JiriTousek我們可以在兩種方法之間取得最佳性能，不是嗎？我可以編輯我的文章，並避免它。 – Sayros

您是否問到兩者之間的性能差異，或者何時使用哪種方法？ –

對於第一種方法（在容器中定義的DataSource的JNDI查找）一些要點：

可以不接觸實際應用
它是能夠確保敏感信息被配置（如密碼）更好
數據源可以許多應用之間的相同服務器

上共享

在需要時，我使用第一種安全（或「安全」）原因的方法 - 通常，客戶的要求是數據庫訪問密碼不得以純文本形式存儲在應用程序中。對此的一種可能的迴應是簡單地不在所有的應用程序中存儲密碼，而是將其留給客戶通過JNDI提供數據源。

從系統管理的角度來看，這也很有意義 - 如果數據源需要重新配置，它可能是由於某些基礎架構或網絡更改造成的，因此它應該在管理員的權力中（以及他們的責任）來重新配置數據源。 servlet容器應該是這樣的地方。

如果我不需要上述任何一種，我使用第二種方法（更簡單，更容易部署）。

來源

2016-03-17 09:35:39

如果有多個應用程序使用您的數據庫。我們可以在容器中配置DataSource，而不是讓每個應用程序管理其數據庫配置，我們將讓應用程序指向該共享配置。這也將幫助您在所有應用程序間共享Db連接池。

對不起，我剛纔搜索發現，類似的答案在SO（否則我也不會公佈這個答案）當你必須環境之間移動應用

JNDI真正的亮點：發展到集成測試到生產。如果你配置每個應用服務器使用相同的JNDI名稱，你可以在每個環境中有不同的數據庫，而不必更改你的代碼。您只需選取WAR文件並將其放入新的環境中即可。

這裏有一些其他的假設是判斷時，這個答案就知道是至關重要的：

我沒有獲得關於該代碼部署在所有的服務器，除了只讀訪問日誌。打包代碼和打包代碼不一樣的人配置和管理服務器。一旦WAR文件開始執行PROD時，它不能再更改，而不會回到開頭。如果WAR發生改變，那麼測試服務器上由QA執行的任何測試都必須重新進行。也許你沒有看到這種好處，因爲你是一個獨立的開發人員，他們在本地桌面上編寫代碼並部署生產權。

來源：Why use JNDI

來源

2016-03-17 09:42:17 Pragnani

感謝您的回覆;）這是幫助。 – Sayros

大聲笑我看到了不同，我使用兩種環境：發展和生產（與液體）:)，謝謝，現在很清楚:) – Sayros

通過tomcat上下文文件和spring context聲明數據源之間的區別

回答

相關問題