提交数据

提交数据（共6篇）

提交数据 篇1

在以http协议提交数据到服务器时, 最常用的就是GET和POST方式。GET方式会把用户提交的数据添加到URL字符串的后面, 这种方式提交数据, 不安全, 且不能提交大量的数据。采用POST方式提交数据时, 则是把用户提交的数据放在Http请求的数据体中, 这种方式相对安全且能提交大量的数据。

采用Get方式提交数据到服务器示例代码如下:

String path="192.168.0.100/web/Login Server?name+"+name;//定义提交的路径, 并向服务器提交一个名称为name的字段。服务器应有接受该字段的处理程序。注意的是path路径不能写成localhost或127.0.0.1, 因为android系统本身也是一个操作系统, 如果这样写, 会指向模拟器本身

URL url=new URL (path) ;//把path封装成URL对象

Http URLConnection conn= (Http URLConnection) url.open Connection () ;//建立连接

conn.set Request Method ("GET") ;//设置请求方式为GET

采用POST方式提交数据到服务器示例代码如下:

String path="http://10.6.161.24:8080/web/Login Servlet";//定义提交路径

URL url=new URL (path) ;

Http URLConnection conn= (Http URLConnection) url.open Connection () ;

conn.set Request Method ("POST") ;//设置请求方式为POST

String date="name="+URLEncoder.encode (name) ;//准备数据

conn.set Request Property ("Content-Type", "application/x-wwwform-urlencoded") ;//设置请求数据类型

conn.set Request Property ("Content-Length", date.length () +"") ;//设置请求数据的长度

conn.set Do Output (true) ;//允许向服务器写数据

Output Stream os=conn.get Output Stream () ;//获得输出流

os.write (date.get Bytes () ) ;//写数据

Http Client是向服务器交互的一个开源框架, google工程师也觉得该框架非常好用, 所以把该框架直接集成到了android的SDK中, 可以直接拿来用。用该框架向服务器提交数据的方式类似于我们用浏览器上网, 第一步先打开浏览器, 第二步输入地址, 第三步敲击回车。

采用Http Client框架利用Get方式提交数据到服务器实例代码如下:

Http Client client=new Default Http Client () ;//获取Http Client对象, 类似与打开浏览器

String path="192.168.0.100/web/Login Server?name+"+name;

Http Get http Get=new Http Get (path) ;//获取Http Get对象, 采用get方式提交, 类似于输入地址

Http Response response=client.execute (http Get) ;//提交数据, 类似于敲击回车。

采用Http Client框架利用Post方式提交数据到服务器实例代码如下:

Http Client client=new Default Http Client () ;

String path="http://10.6.161.24:8080/web/Login Servlet";

Http Post post=new Http Post (path) ;//获取Http Post对象, 采用Post方式提交

List<Name Value Pair>parameters=new Array List<Name ValuePair> () ;//封装要提交的数据

parameters.add (new Basic Name Value Pair ("name", name) ) ;

post.set Entity (new Url Encoded Form Entity (parameters, ) ) ;//设置要提交的数据

Http Response response=client.execute (post) ;

Async Http Client是向服务器提交数据的另外一个框架, 该框架是基于回掉机制的。采用异步提交的方式提交数据。在采用http协议或Http Client框架提交数据的时候, 由于连接服务器可能是非常耗时的操作, 所以需要把连接服务器的代码放在子线程中。而采用Async Http Client方式时不用担心这个问题。

采用Async Http Client框架利用Get方式提交数据到服务器实例代码如下:

采用Async Http Client框架利用Post方式提交数据到服务器实例代码如下:

从以上三种提交数据到服务器的方式不难看出, 编程方式变得越来越简单。其实Http Client是对采用Http协议的封装, 而Async Http Client又是对Http Client的封装。

摘要：在Android应用程序开发中, 经常要提交数据到服务器, 并从服务器获取数据。文章主要介绍基于http协议提交数据到服务器, 采用Http Client提交数据到服务器, 以及采用异步Async Http Client框架提交数据到服务器。

关键词：Http,HttpClient,AsyncHttpClient

参考文献

[1]明日科技.Android从入门到精通[M].清华大学出版社, 2012 (9) .

[2]张余.Android网络开发从入门到精通[M].清华大学出版社, 2014 (1) .

[3]李刚.疯狂Android讲义 (第二版) [M].电子工业出版社, 2013 (3) .

提交数据 篇2

这种方法会让你一开始就受益，在你提交网站的时候会帮你节省时间.你在提交到不同网站目录的时候可能需要调整部分信息。因为它们都有不同的提交要求。你应该小心地遵照它们的要求，尽可能地减少它们的编辑会改动你提交的信息的风险，争取最后列出的信息是以你的表述展现的，而没有被改动过。

从一开始，就要一而再、再而三地对拼写进行检查.如果拼写的词组没有语法问题的话，语法检查器无法对误拼进行检查。在你把提交表格打印出来后，你就会发现这些不同的网站目录中有许多通用的元素要求。为网站上每个要被索引的页面需要准备的信息包括：

●URL：

●页面标题;

●10个字、25个字、50个字争100个字的页面描述(不同的引擎允许不同长度的描述信息);

●每个页面的关键字列表(按照第2章里面所说的，基于你所生成的主要关键字列表);

●网站目标受众的描述：

●在不同网站目录上你所期望提交到的分类和子分类列表：

●联系信息;

特别注意标题和表述,在标题和描述上一定要小心、仔细，

在显示页面标题的时候，网站目录通会严格限制你的公司名称。有时候，它们会给你额外一栏填写描述性标签，无论如何，你的公司名称都要准确表明你的业务。正确地标识符号和注册资本都是必须的。

最好能够撰写一系列不同长度的描述，以适应不同网站目录所允许描述的不同长度。你可以从撰写10个字、25个字、50个字或100个字的描述开始。一定要确保你在每个目录中使用了正确长度的描述，否则它在搜索结果里面的显示可能会完全变掉。如果你的提交不符合网站目录的标准原则，编辑们则可能在修改你的描述时敷衍了事，或者随意按照他们个人的风格。当你提交到一个特定网站目录的时候，不妨先看看同一分类下其他人常用的描述方式，然后修改你自己的描述以符合整体风格。

你的描述应当引人注目。当你的网站出现在一个搜索结果的前两页时，描述就是让你的网站区别于其他网站的利器。正是这些描述刺激潜在用户点击、访问你的网站——或者匆匆掠过，转而去另一个他们更感兴趣的网站。

提交数据 篇3

1 基本两阶段提交协议(2PC)

在基本2PC协议中,分布式事务处理程序要任命一个协调者,该协调者负责分布式事务的提交或中止。该协调者一般由分布式事务的始发站点上的代理者担任,其它站点上的代理者被称为分布式事务的参与者,每个参与者负责其局部事务并向协调者提出提交或中止事务的请求。

基本2PC协议的基本思想是只有全部子事务均提交的情况下分布式事务才会提交;如果有一个参与者不能提交其子事务则全部子事务都中止。保证所有参与者做出提交或撤销子事务的统一决定。基本2PC协议由两个阶段组成,第一阶段做出提交或撤销全部子事务的决定,称之为决策阶段;第二阶段执行第一阶段的决定,称之为执行阶段。

在基本2PC协议的第一阶段,协调者给所有的参与者发消息进入预提交阶段,如果参与者就绪了并同意提交,就回答“提交”。在发送预提交命令之前,协调者要在日志中写入预提交记录以及所有参与者的子事务标识,然后协调者进入等待回应状态并启动计时器。当一个参与者回答“准备提交”时,要保证在其它站点故障时也能提交子事务。因此,在各子事务所在站点的日志中要记录以下内容:

1)本站点提交子事务所需的全部运行记录。

2)该子事务已准备就绪的记录。

以上两点保证该子事务的状态不受其它站点故障的影响。

在执行阶段,当协调者做出决定后,会在日志中写入“全部提交”或“全部撤销”记录。这保证分布式事务会统一提交或撤销,然后协调者向所有的参与者发送“提交”或“撤销”命令。

所有的参与者根据协调者的命令将“提交”或“撤销”记录写入本站点日志中。同时执行“提交”或“撤销”命令并向协调者发送“执行”消息。

协调者从所有参与者处收到执行消息,在日志中写入“完成”记录,至此分布式事务完成。

2 基本两阶段提交协议问题分析

在基本2PC协议中,参与者在同意提交之前,可以任意终止自己的子事务。而在参与者确定了子事务的提交或撤销后,就不能再更改它的建议,必须等待协调者的最终决策。在这个期间,协调者和参与者都进入相互等待对方发送消息的状态,当与协调者和参与者相关的通信网络不稳定,特别是发生网络故障时,就很容易引发事务处理的非正常阻塞现象,这时该事务所占用的资源长期不能或根本不能释放,占用其它事务的资源,影响其它事务的处理,降低了系统的工作效率和可靠性。

另外,如图1所示,协调者非常关键,如果协调者发生故障,势必会对严重影响全局事务。协调者和参与者需要通过网络传递准备提交、建议提交或撤销、全局提交或撤销和提交或撤销信息。当参与者较多时,协调者要与每一个参与者直接进行通信,处理信息量大,响应时间就会长。这时协调者就会成为事务处理的瓶颈。网络也会出现不稳定或有故障的现象,由此也会引发事务处理的非正常阻塞状态。

由以上分析可见,非正常阻塞是影响基本2PC协议性能的关键因素。如果要提高分布式数据库系统的工作效率和可靠性,就必须降低非正常阻塞的发生几率,并尽可能的减少已出现的非正常阻塞对系统的影响。

3 两阶段提交协议的一些改进

为了减轻了协调站点的负担,防止协调者出错造成事务无法完成,并缩短各子事务并行处理的响应时间,确保协调者和参与者能够从非正常阻塞状态中退出并终止。本文对基本两阶段提交协议做了如下改进:

1)提供一个辅助协调者站点,在协调者站点出现故障的情况下接替协调者的职能,完成事务处理。

2)为每个进程设置一个定时器。如果某个进程所期待的消息在计时器超时之前还未到达,就进行超时处理,从而提高分布式数据库系统效率、可靠性和可用性。

改进后的方案中,在进行分布式事务处理时,由系统选定一个协调者、一个辅助协调者和完成该事务所需的所有参与者。在第一阶段,协调者向辅助协调者和所有参与者发送命令,并将辅助协调者的地址和所有参与者的地址作为附加信息在命令中一起发送。协调者将命令发出后就立即启动定时器并进入等待状态,等待接收参与者发回的回应消息。如果参与者在收到消息前发生站点故障,参与者站点会先自行进行故障恢复,如不能恢复,则直接终止全局事务,这样可以减少无谓事务的提交。如果参与者正常,参与者收到命令后,根据定时器的时间限制和本地资源情况向本地站点申请进行子事务提交所需的本地资源。如果本地资源符合事务提交条件,则发送“建议提交”消息,同时启动定时器,进入等待状态,等待协调者发送全局事务的最终决策;如果参与者没有申请到足够的进行子事务提交的本地资源,则向协调者发送“建议撤销”消息,并撤销本地资源的申请。在第二阶段中,协调者如果在定时器规定的时间内未能收到所有参与者的消息,则全局事务撤销;如果协调者收到所有参与者的消息,则根据参与者发过来的消息是提交还是撤销来做出全局事务的决策。如果收到的参与者发送的消息均为“建议提交”,则协调者通过辅助协调者向所有参与者发送“全局提交”命令,否则协调者通过辅助协调者向那些发送“建议提交”的参与者发送“全局撤销”的命令,同时将上述操作记入日志中。在执行阶段中,参与者如果在定时器规定的时间内,收到协调者关于全局事务的最终决策,则按照协调者的命令进行相应的事务处理。否则,参与者根据初始命令报文中的辅助协调者地址和其它参与站点地址向这些站点询问协调者的最终决策,根据得到的回复来决定提交或撤销事务。同时将操作确认信息发送给协调者。参与者也要将上述操作记入本地日志中,在出现站点故障时用来进行重启恢复。最后,协调者等待收到所有参与者发回的确认信息后再在日志中写入“事务结束”记录。

如图2所示,协调者向辅助协调者和各个参与者发送命令,所有参与者如果正常工作并建议提交,则由辅助协调者把建议发送给协调者。这样相比于基本2PC协议中在各站点能正常通信并且无故障的时候确实增加了报文通信,但是当协调者发生故障时却可以保证整个系统的可靠运行。假如协调者收到各参与者发来的建议消息后发生故障时,协调者无法与辅助协调者通信,这时辅助协调者会根据系统的超时控制机制来确定协调者出现故障,由于辅助协调者记录有所有参与者的建议信息,辅助协调者可以执行协调者的职能。辅助协调者在执行协调者职能时协调者有可能恢复故障,这时系统中就会出现两个协调者,为防止这种情况发生,辅助协调者首先发送一条消息给协调者表示要执行协调者的职能,即使协调者后来排除故障恢复了,它首先要处理来自辅助协调者的这条消息,协调者收到这条消息后就放弃协调者角色,进入等待状态。辅助协调者根据刚才收到的所有参与者建议消息作出提交或撤销事务的决策。当事务结束后,辅助协调者要发送一条消息给协调者表示事务结束,辅助协调者也就不再执行协调者的职能。如果当辅助协调者在发送决策命令后发生故障,就不能执行该事务也不能把事务结束的信息发给协调者,系统会根据超时控制机制判断辅助协调者已经发生故障,这时协调者如果恢复了就会退出等待状态,重新执行协调者职能,协调者也会首先发送一条消息给辅助协调者表示要重新执行协调者职能,协调者会根据日志记录重新发送决策给所有参与者继续把事务完成。

在改进方案中,各参与站点在全局事务发起前会进行故障检测,如有站点发生故障则重启恢复,避免无用的事务提交。在协议进行的各个阶段普遍采用超时控制机制来检测故障,防止多个站点出现长时间互相等待,当部分站点出现故障而引发超时情况时,正常站点可以通过终止程序终结事务,减少因等待导致的阻塞状况出现。辅助协调站点的使用减少了协调站点的负担,而且在协调站点发生故障失效时转变职能成为新协调者,使参与者可立即结束等待状态,从另一方面减少了阻塞情况的出现。

4 结束语

基本两阶段提交协议(2PC)在分布式数据库系统的实现中被广泛采用,但因其容易引起阻塞状态等缺陷而影响系统的工作性能。本文针对基本2PC协议的实现方法的不足,提出了一个改进方案。这种方案可以有效减少非正常阻塞发生的几率并提高分布式数据库系统的性能。

摘要：分布式数据库具有可靠性和并行性等优点。在实现分布式数据库的过程中需要解决的最关键的问题是保证分布式事务的原子性、一致性、隔离性和持久性。两阶段提交协议可以解决这个问题,但是也存在一些缺陷。研究分布式数据库的事务处理机制,对基本两阶段提交协议所存在问题做了详细的分析并提出了一种两阶段提交协议的改进方案。

关键词：分布式数据库,事务,两阶段提交协议,阻塞

参考文献

[1]邵佩英.分布式数据库系统及其应用[M].北京:科学出版社,2000.

[2]熊燕群,白似雪.DDBMS的两阶段提交协议中阻塞问题的解决方案[J].计算机应用与软件,2006,23(5).

[3]宋静,刘心松,赖周建,等.一种改进的2PC协议及其性能[J].微计算机信息,2006(22):3-4.

[4]赵淑芳.分布式数据库事务处理[J].机械管理开发,2006(4):33-37.

[5]胡勇,陈炬华.分布式数据库的事务协议[J].情报杂志,2004(2):23-27.

单品提交标准 篇4

1、企业营业执照副本复印件（需完成有效年检且所售商品属于经营范围内）；

2、企业税务登记证复印件（国税加地税）；

3、组织机构代码证复印件；

4、银行开户许可证；

5、法定代表人身份证正反面复印件；

二、产品证件：

1、食品流通许可证（食品类需提交）；

2、商标注册证；

3、商标权人出具的授权书；

4、质检报告复印件或产品质量合格证明（不同品牌不同类目产品均需提供一份）；

三、特殊产品资质审核

1、化妆品商品商家：

 化妆品生产厂商持有的《化妆品卫生许可证》复印件；

 《化妆品生产许可证》（即《全国工业产品生产许可证》）复印件；

 化妆品生产厂商的营业执照副本复印件；

 部分商品检验检疫合格的报告或证明复印件；

2、进口化妆品商品商家：

 海关进口货物报关单复印件；

 出入境检验检疫入境货物检验检疫证明复印件；

 进口非特殊用途化妆品备案凭证复印件；

 商品需带有CIQ表示和中文标签；

3、食品商品商家：

 《食品卫生许可证》或《食品流通许可证》复印件；

 《食品生产许可证》复印件；

 如系进口食品还须商品出入境检验检疫合格证明、《卫生证书》复印件以及报关单；  如系酒类销售还须提供《酒类零售许可证》或《酒类流通备案登记表》复印件；  如系蔬果、生鲜商品还须提供产地证明及卫生检疫合格证明复印件；

四、单品支持要求：

1、产品基本信息：产品名称、产品规格、产品款式、含包装重量、产品文字介绍；

2、产品图片：焦点图1张（800*800）、产品高清图6张、产品包装图3张；

3、产品物流信息：快递名称、运费起步、运费续重；

4、产品链接：优先选择淘宝、天猫、京东、1号店等零售平台产品展示链接；

五、产品发货及售后需求：

1、支持提交订单后24小时内发货并及时反馈快递单号；

2、支持无条件7天免费退换货；

3、支持零售平台单件发货；

4、支持全国各地区配送，不配送地区标注；

提交数据 篇5

数据库的特点是数据的集中管理和共享。在通常情况下若干事务可能并发地存取相同的数据,称为事务的并发操作。为了保证数据库的一致性,需要运用并发控制。分布式数据库的并发控制是以集中式数据库的并发控制技术为基础的[1]。2PL下的冲突可以分为执行-执行冲突和执行-提交冲突。运用乐观方法(OPT)可以对执行-提交冲突加以解决。乐观方法允许执行事务访问与其有冲突的提交事务所封锁的数据项,从而不但解决了执行-提交冲突,还提高了事务处理的并发度[2]。但在解决写-写冲突时存在不足,为此本文提出了一种改进的乐观方法。

2. 解决2PL执行-提交冲突的乐观方法

2.1 2PL执行-提交冲突

两阶段锁定协议(2PL)要求每个事务分两个阶段提出上锁和解锁申请:(1)增长阶段,事务可以获得锁,但不能释放锁;(2)缩减阶段,事务可以释放锁,但不能获得新锁。分布式两阶段锁定协议(D2PL)是2PL在分布式环境下的拓展。

在两阶段提交协议2PC中,事务在原发站点上的进程被称为协调者,在其它站点上的进程被称为参与者。它的工作期分为投票和决定两个阶段。协议的工作过程如图1所示[3]:

事务的生命周期也被分为两个阶段:执行阶段和提交阶段。在执行阶段,分布式事务的各个子事务在分布式系统的各个站点上被执行;在提交阶段,各个子事务提交自己的执行结果,这时需要2PC来保证分布式事务执行的原子性。而分布式两阶段锁定协议(D2PL)运转在事务的整个生命周期。

从图2中可以看出,在事务生命周期的第一阶段(执行阶段)中,事务经过D2PL的增长阶段(用于申请锁并且进行相应的数据访问)和部分收缩阶段(可用于完成最后被锁数据的访问);当事务的所有数据处理操作完成之后,事务进入生命周期的第二阶段(提交阶段),在这段时期中,事务经过2PC的工作期(包括投票阶段和决定阶段)。

一个处于执行阶段的子事务和一个处于提交阶段的子事务可能发生锁冲突,因为前者有申请锁的行为,而后者占有一些锁没释放,这种冲突被称为执行-提交冲突。

2.2 解决2PL执行-提交冲突的乐观方法

目前,提出的比较优秀的专门处理执行-提交冲突的方法有乐观方法(OPT)及它的两个变形体———Shadow-Opt和Healthy-Opt。乐观方法允许执行事务访问与其有冲突的提交事务所封锁的数据项,从而不但解决了执行-提交冲突,而且还提高了事务处理的并发度。它的基本思想概述如下:

首先,为了保持事务的可串行性,它需要两个依赖集:提交依赖集和回滚依赖集。其次,为了在不破坏数据库一致性的基础上实现冲突模式下的并发访问,为数据库中有访问冲突的数据项x保存三种副本,注意这是不同于多版本数据库的。这三种副本被称为数据项x的前提交值BV(x),后提交值AV(x),和进一步提交值FV(x)。BV(x)存储x的最近一次的提交值。如果事务刚写下x,这个新写的值就将被保存到AV(x)中,用作x未来的提交值。FV(x)用来解决写一写冲突。下面简述一下乐观方法是怎样解决执行-提交冲突的。

情况1:解决读-写冲突。如果提交事务T1持有数据项x的读锁,而执行事务T2又来申请x的写锁。此时T2可不被阻塞,而在AV(x)中写x的后提交值并继续执行。但从此T2便提交依赖于T1,所以将标记号T1记录进T2的提交依赖集中。T1结束后(提交成功或回滚),才允许T2提交(进入提交协议的决定期)。若T2提交成功,将AV(x)拷入BV(x)。

情况2:解决写-写冲突。如果提交事务T1持有数据项x的写锁,而执行事务T2又来申请x的写锁。此时T2可不被阻塞,而在FV(x)中写x的进一步提交值并继续执行。但从此T2便提交依赖于T1,所以将标记号T1记录进T2的提交依赖集中。T1结束后(提交成功或回滚),可将FV(x)拷入AV(x),并且允许T2提交。

情况3:解决写-读冲突。如果提交事务T1持有数据项x的写锁,而执行事务T2又来申请x的读锁。此时T2也可不必被阻塞,而从AV(x)中读取x的后提交值并继续执行。但从此T2便回滚依赖于T1,所以将标记号T1记录进T2的回滚依赖集中。若T1回滚,T2必须也得回滚,并且在T1完成之前,不允许T2进入提交协议的决定期。因为一旦进入决定期,就不能更改提交命令。

仔细分析情况2不难看出,若T1回滚后将FV(x)拷入AV(x),并且允许T2提交,则可能造成数据库的不一致。比如数据项x的初始值为100,T1为x=x+10;T2为x=x+10。则BV(x)为100,T1执行后AV(x)为110,此时T2在FV(x)中写入的值为120。假设T1回滚,将FV(x)拷入AV(x),则AV(x)的值为120,而事实上只执行了T2,即AV(x)的值应为110,造成了数据库的不一致。

当然,若T1为x=200;T2为x=300,则不会出现不一致的情况。

3. 对解决2PL执行-提交冲突的乐观方法的修正和改进

3.1 对解决2PL执行-提交冲突的乐观方法的修正

对写-写冲突处理方案的修正并不困难,比如(1)类似写-读冲突处理方案,将“T2提交依赖于T1”改为“T2回滚依赖于T1”[4];(2)运用Shadow–Opt方法。

Shadow–Opt方法是指T2在第一次获取其它活动事务T1(即未提交或回滚事务)锁定的数据项时,启动T2的一个影子事务。然后该影子事务挂起。若T1提交,则放弃该影子事务;若T1回滚,则放弃T2并启动其影子事务[5]。如果T2在第一次获取其它活动事务T1锁定的数据项是在本身即将结束时,那么Shadow–Opt方法效率较高;如果T2在第一次获取其它活动事务T1锁定的数据项是在本身刚刚开始不久,则Shadow–Opt方法和将“T2提交依赖于T1”改为“T2回滚依赖于T1”无太大差别。

3.2 对解决2PL执行-提交冲突的乐观方法的改进

以上两种修正方法都能保证数据库的一致性,但都会导致T2重启或近似重启。乐观条件下的重启是在事务执行完成后做出的,因而代价比较大,应尽量避免;而T2提交依赖于T1可以保证避免重启,并且不一定会导致数据库的不一致。综合此两点,本文对解决2PL执行-提交冲突的乐观方法做出如下改进:

首先,将写操作分为包含读的写和不包含读的写操作两类。包含读的写操作的结果依赖于原值,比如w(x):x=x+10;不包含读的写操作的结果不依赖于原值,比如w(x):x=200。

情况1:解决读-写冲突。如果提交事务T1持有数据项x的读锁,而执行事务T2又来申请x的写锁。因为此冲突条件下不论T2的写操作包含不包含读,T2提交依赖于T1都不会导致数据库的不一致,原方案不做任何变化。

情况2:解决写-写冲突。如果提交事务T1持有数据项x的写锁,而执行事务T2又来申请x的写锁。(1)如果T2的写操作是不包含读的写操作,则此时T2可不被阻塞,而在FV(x)中写x的进一步提交值并继续执行。从此T2便提交依赖于T1,所以将标记号T1记录进T2的提交依赖集中。T1结束后(提交成功或回滚),可将FV(x)拷入AV(x),并且允许T2提交;(2)如果T2的写操作是包含读的写操作,则运用Shadow–Opt方法。在T2在第一次获取T1锁定的数据项时,启动T2的一个影子事务。然后该影子事务挂起。若T1提交,则放弃该影子事务;若T1回滚,则放弃T2并启动其影子事务。

情况3:解决写-读冲突。如果提交事务T1持有数据项x的写锁,而执行事务T2又来申请x的读锁。因为此冲突条件下不论T1的写操作包含不包含读,T2提交依赖于T1都会导致数据库的不一致,原方案不做任何变化。

如何区分一个写操作包含读还是不包含读呢?

任何一个对数据项x的写操作都可用一个函数表示,即AV(x)=f(x1,x2,x3……xn),其中x1,x2,x3……xn为若干数据项,如果x∈{x1,x2,x3……xn},则表示对数据项x的写操作包含对本身的读;否则,该写操作不包含对本身的读。

4. 并发控制锁模式之间冲突本质的探究和新冲突表的构建

传统的并发控制锁模式之间的冲突本质等价于至少其中一个锁模式为写锁,其冲突表如表1:

*表示锁模式之间的冲突

通过上面的分析可知,至少其中一个锁模式为写锁只是并发控制锁模式之间冲突的必要条件而非充分条件。并发控制锁模式之间冲突本质等价于至少其中一个锁模式为写锁并且两个锁模式不同时为不含读的写锁。其冲突表如表2:

*表示锁模式之间的冲突

5. 结论

通过对解决分布式数据库2PL执行-提交冲突的乐观方法的分析,发现写-写冲突处理方案有可能导致数据库的不一致性。给出了两种修正方法:(1)将“T2提交依赖于T1”改为“T2回滚依赖于T1”;(2)运用Shadow–Opt方法。并将修正后的方法和原方法结合,确保了数据库一致性并且提高了算法性能。最后据此探究了并发控制锁模式之间冲突的本质,构建了新的冲突表,增加了事务的并发程度。

参考文献

[1]邵佩英.分布式数据库系统及其应用[M].北京:科学出版社,2005.

[2]熊燕群,白似雪,李进京.分布式实时数据库系统的事务管理[J].南昌大学学报(理科版),2008,32(5):290-294.

[3]Lam Kam-yiu,Pang Chung-leung,Sang H.Son.Resolving Executing-Committing Conflicts in Distributed Real-time Database Systems[J].The Computer Journal,1999,42(8):674-676.

[4]Gupta R,Haritsa J,Ramamritham Ketal.Commit processing in distributed real-time database systems[C].Proceeding of the17th IEEE Real-time Systems Symposium,Washington,DC,1996:123-133.

外贸发展提交优异答卷 篇6

2015年,我国外贸发展面临的形势依然复杂严峻,企业仍将面临不少困难。面对新形势、新挑战,商务部将继续深入推进稳增长政策落实工作。

2014年,我国外贸发展形势复杂严峻。1-4月,外贸出现了多年不遇的进出口和出口“双下降”的情况。党中央、国务院高度重视,及时出台了支持外贸稳定增长和加强进口的政策文件。各部门、各地方以空前力度抓落实,出台一系列务实举措,有效提振了企业信心,激发了市场主体活力。5月份以后,我国进出口增长开始企稳回升,外贸稳增长、调结构取得积极成效。

质量效益进一步提高

据海关统计,2014年,我国进出口总额43030.4亿美元,同比增长3.4%,其中出口23427.5亿美元,同比增长6.1%,进口19602.9亿美元,同比增长0.4%。贸易顺差3824.6亿美元,扩大47.7%。

2014年,我国外贸保持平稳增长,进出口增速快于世界主要经济体和新兴发展中国家,占全球市场份额稳中有升,继续保持全球第一大货物贸易大国地位。如果剔除2014年部分月份异常贸易垫高基数影响,我国进出口实际增长6.1%,出口实际增长8.7%,超过去年年初预期增长目标。在保持外贸平稳增长的同时,我国外贸发展的质量和效益总体有所提升。

突出表现在九个方面

一是我国外贸增长速度仍高于世界主要经济体。据我国和主要贸易伙伴海关统计,2014年1-11月,我进出口增速分别超出美国、欧盟(1-10月)、日本0.4、3.1、5.8个百分点,超出印度(1-10月)、巴西5.2、8.7个百分点。

二是国际市场份额稳中有升。有望继续保持全球第一贸易大国地位,份额稳中有升。从WTO 2014年1-9月的数据看,我占全球贸易的份额约为12.2%,高于2013年1个百分点。

三是国际市场布局更趋合理。新兴市场和发展中国家占出口比重进一步提升。2014年,我对新兴市场和发展中国家出口占总出口比重45.4%,比2013年提高1.6个百分点。

四是国内区域布局进一步优化。中西部地区外贸发展能力增强,占全国外贸的比重进一步提升。2014年,中西部地区进出口增速14.8%,同比提高0.8个百分点,占全国的比重为15.4%,较2013年上升了1.5个百分点。

五是出口商品结构进一步优化。大型成套设备、特色产品出口高速增长。2014年,电力、通讯、机车车辆等大型成套设备出口继续快速增长,增速达10%以上,出口占比为4.7%,比2013年提高0.2个百分点。机电产品占出口总额的比重已达56.0%。

六是经营主体结构进一步优化。民营企业成为最具活力和出口潜力的经营主体。2014年,民营企业出口增长10.4%,占我国出口总值的43.2%,比2013年提高1.7个百分点,贡献全国出口增量的71.8%。

七是贸易方式进一步优化。2014年,一般贸易出口同比增长10.7%,占出口总值比重为51.4%,全年占比20年来首次过半,对出口增长的贡献率达87.8%。

八是新型贸易模式蓬勃发展。跨境电子商务、市场采购等新型贸易方式正逐步成为外贸发展新的增长点。2014年,跨境电子商务增速高达30%以上。义乌市场采购贸易方式出口192.9亿美元,增速达36.8%。

九是进口效益有所提升。大宗商品进口价格下跌但量增,在满足国内生产需要的同时,有效降低了企业的进口成本,提高了进口效益。