mvc怎么修改web.config来连接mysql数据库

mvc怎么修改web.config来连接mysql数据库,第1张

在网站开发中,数据库 *** 作是经常要用到的 *** 作,ASP.NET中一般做法是在web.config中配置数据库连接代码,然后在程序中调用数据库连接代码,这样做的好处就是当数据库连接代码需要改变的时候,我们只要修改web.config中的数据库连接代码即可,而不必在修改每一个页面中的数据库连接代码。

在ASP.NET中有两种配置数据库连接代码的方式,它们分别是 appSettings 和 connectionStrings 。在使用 appSettings 和 connectionStrings 配置数据库连接代码时,可分别在 <configuration>下添加如下代码:

1. appSettings

<appSettings>

    <add key="conn" value="server=服务器名database=数据库名uid=用户名password=密码"/>

</appSettings>

2. connectionStrings

<connectionStrings>

    <add name="conn" connectionString="Dserver=服务器名database=数据库名uid=用户名password=密码" providerName="System.Data.SqlClient" />

</connectionStrings>

appSettings 和 connectionStrings 的区别:(摘自http://www.cnblogs.com/kerry1986/archive/2009/07/08/1518895.html)

(1) appSettings 是在 2003 中常用的,connectionStrings 是在 2005 中常用的;

(2) 使用 connectionStrings 的好处:

第一,可将连接字符串加密,使用MS的一个加密工具即可;

第二,可直接绑定数据源控件,而不必写代码读出来再赋值给控件;

第三,可方便的更换数据库平台,如换为 Oracle 数据库,只需要修改 providerName。

(3) 写在 appSettings 中用 System.Configuration.ConfigurationManager.AppSettings["keyname"] 获取数据库连接代码值;写在 connectionStrings 中用 System.Configuration.ConfigurationManager.ConnectionStrings["name"] 获取数据库连接代码值。

先来总体说一下我对这个问题的理解,用一句话概括:

数据库是可以控制事务的传播和隔离级别的,Spring在之上又进一步进行了封装,可以在不同的项目、不同的 *** 作中再次对事务的传播行为和隔离级别进行策略控制。

注意:Spring不仅可以控制事务传播行为(PROPAGATION_REQUIRED等),还可以控制事务隔离级别(ISOLATION_READ_UNCOMMITTED等)。

(以下是个人理解,如果有瑕疵请及时指正)

下面我具体解释一下:

为了大家能够更好的理解,先来明确几个知识点:

事务的传播行为:简单来说就是事务是手动提交还是自动提交,事务什么时候开始,什么时候提交。

事务的隔离级别:简单来说,就四个,提交读,提交读,重复读,序列化读。

首先我来描述一下,数据库(mysql)层面上对于事务传播行为和隔离级别的配置和实验方法:

数据库层面(采用命令行):其实mySql命令行很简单,希望实验 *** 作一下:

//连接数据库,我这里是本地,后面是用户名密码,不要打分号,如果指令不行,配置下环境变量,网上有很多。

1. cmd中执行:mysql -hlocalhost -uroot -pmysql

//查看本地数据库事务传播行为是手动提交(0),还是自动提交(1)。

2.select @@autocommit

//如果是0,希望设置为手动提交,这里其实是设置本对话的autocommit,因为如果你再开一个cmd,发现还是没改回来,如果想修改全局的,网上有global方法。

3.set @@autocommit=0

//然后查询本地数据库中的一条记录,我本地数据库为test1

4.use test1

5.select * from task where taskid=1

//同时新开一个窗口cmd,连接数据库,并且修改这条记录,update语句我就不写了,或者直接修改数据库本条记录。

//再次执行select * from task where taskid=1发现值没变。OK因为此时数据库隔离级别为repeatable read 重复读,因为mysql默认的隔离级别是重复读。

//修改数据库隔离级别

6.set global transaction isolation level read committed

//查看一下,可能需要重新连接一下

7.select @@tx_isolation

//这时在执行一下4,5 *** 作,发现值变了,ok。因为已经改变了数据库隔离级别,发生了重复读出不同数据的现象。

(以上 *** 作希望有不明白的上网自学一下,很有用,先把数据库隔离级别弄明白了)

然后再来讲一下,Spring对事务传播行为和隔离级别的二次封装。

因为不同项目可能在一个mysql的不同数据库上,所以可以在项目中配置数据库的传播行为和隔离级别:

关于spring的传播行为(PROPAGATION_REQUIRED、PROPAGATION_REQUIRED等),我《数据库隔离级别(mysql+Spring)与性能分析 》文章中有讲,网上也有很多相关资料,我就不说了。

关于spring的事务隔离级别与数据库的一样,也是那四个,多了一个default,我也不仔细讲了。

下面主要讲一下spring的配置方法:

<property name="transactionAttributes">

<props>

<prop key="save*">PROPAGATION_REQUIRED</prop>

<prop key="update*">PROPAGATION_REQUIRED</prop>

<prop key="delete*">PROPAGATION_REQUIRED</prop>

<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>

<prop key="find*">PROPAGATION_REQUIRED,ISOLATION_READ_UNCOMMITTED</prop>

</props>

就以find为例,可以配置这么配置,前面是控制传播行为,后面是控制事务隔离级别的。那么这时哪怕数据库层面上是重复读,但是还是以这里为准,你会发现在同一个事务中两次查询的结果是不一样的。

最后扫除一个盲区,readonly这个属性,是放在传播行为中的,一般书都这么归类,我也尝试了一下,readonly并不能影响数据库隔离级别,只是配置之后,不允许在事务中对数据库进行修改 *** 作,仅此而已。

场景描述:有多个数据库,每个数据库可能分布在不同的mysql instance上面,有多个存储过程,每个存储过程可能分布在不同的数据库中,需要有两个配置文件。

1. mysql 数据库映射:

A.driverClassName=com.mysql.jdbc.Driver

A.url=jdbc:mysql://172.20.7.51:3308/blog

A.username=trappuser

A.password=Opera1!

B.driverClassName=com.mysql.jdbc.Driver

B.url=jdbc:mysql://localhost:3306/wedding

B.username=root

B.password=opera

上面定义的A、B为两个mysql instance的缩写。

2. 存储过程与mysql instance的映射关系:

SP_Get_User=A

GetStocks=B

定义两个模拟存储过程,第一个数据库“SP_Get_User“是在数据库A下面,第二个数据库”GetStocks“是在数据库B下面。

3. 建立自定义的sessionFactory

3.1 xml配置的datasource及sessionFactory如下:

<bean class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close" id="dataSource">

<property name="driverClassName" value="${database.driverClassName}"/>

<property name="url" value="${database.url}"/>

<property name="username" value="${database.username}"/>

<property name="password" value="${database.password}"/>

</bean>

<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">

<property name="dataSource" ref="dataSource"/>

<property name="packagesToScan" value="com.xx.assetcommander">

</property>

<property name="hibernateProperties">

<props>

<prop key="hibernate.dialect">org.hibernate.dialect.MySQLDialect</prop>

<prop key="hibernate.show_sql">true</prop>

</props>

</property>

</bean>

此处我们定义的sessionFactory的类型为LocalSessionFactoryBean,它是一个工厂对象,与我们再需要的 SessionFactory不是一回事,我们需要的sessionfactory是org.hibernate.SessionFactory,这个对象可以被第一个sessionFactory的getObject()方法生成。

3.2 由于我们连接的是多个mysql instance, 不方便在xml中配置多个datasource和多个sessionFactory,故可以通过纯java的形式开发,可以使用map来存储存储过程与mysql database的关系,将存储过程的名字和数据库建议关系,这样通过存储过程的名称就能得到数据库的缩写名,通过数据库的缩写名能够找到对应的mysql instance,使用纯java开发的过程类似于xml配置,如下:

ds.setDriverClassName(getDriver())

ds.setUrl(getUrl())

ds.setUsername(getUsername())

ds.setPassword(getPassword())

LocalSessionFactoryBean sessionFactory = new LocalSessionFactoryBean()

sessionFactory.setDataSource(ds)

sessionFactory.setPackagesToScan("com.xx.assetcommander")

Properties params = new Properties()

params.setProperty("hibernate.dialect",

"org.hibernate.dialect.MySQLDialect")

params.setProperty("hibernate.show_sql", "true")

sessionFactory.setHibernateProperties(params)

当我们获得可以使用的LocalSessionFactoryBean时候,在调用getObject()获得SessionFactory之前,必须要调用afterPropertiesSet()方法,否则得到的sessionFactory为空。

public Session getDsBySp(String spName) throws IOException {

//get the corresponding mysql database shortname by sp name

String dbName = getDbForSP(str)

//get the corresponding mysql instance connection by mysql database shortname

LocalSessionFactoryBean fB = getDsByDb(dbName)

// don't forget this line or null will be returned when you call getObject() method.

fB.afterPropertiesSet()

return fB.getObject().openSession()

}

注:在tomcat启动时,如果没有配置任何datasource,会出现如下错误:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type [javax.persistence.EntityManagerFactory] is defined

故需要配置默认的datasource.

这种方式需要做到不同的数据库instance直接业务的完全独立,不可以出现跨数据库的表join,否则处理难度会增加。

还有就是对于多数据库直接的事务管理如何去处理?


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/8532290.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-17
下一篇 2023-04-17

发表评论

登录后才能评论

评论列表(0条)

保存