LINQ TO SQL 执行查询时抛出错误 此操作对该事务的状态无效。 求解决方案

1. LINQ TO SQL 执行查询时抛出错误 此操作对该事务的状态无效。 求解决方案

根据你描述的 应该是 数据库中缺少'CreateFiles'这张表

2. java提示这个异常怎么解决

1. java.lang.nullpointerexception
这个异常大家肯定都经常遇到，异常的解释是"程序遇上了空指针"，简单地说就是调用了未经初始化的对象或者是不存在的对象，这个错误经常出现在创建图片，调用数组这些操作中，比如图片未经初始化，或者图片创建时的路径错误等等。对数组操作中出现空指针，很多情况下是一些刚开始学习编程的朋友常犯的错误，即把数组的初始化和数组元素的初始化混淆起来了。数组的初始化是对数组分配需要的空间，而初始化后的数组，其中的元素并没有实例化，依然是空的，所以还需要对每个元素都进行初始化（如果要调用的话）

2. java.lang.classnotfoundexception
这个异常是很多原本在jb等开发环境中开发的程序员，把jb下的程序包放在wtk下编译经常出现的问题，异常的解释是"指定的类不存在"，这里主要考虑一下类的名称和路径是否正确即可，如果是在jb下做的程序包，一般都是默认加上package的，所以转到wtk下后要注意把package的路径加上。

3. java.lang.arithmeticexception
这个异常的解释是"数学运算异常"，比如程序中出现了除以零这样的运算就会出这样的异常，对这种异常，大家就要好好检查一下自己程序中涉及到数学运算的地方，公式是不是有不妥了。

4. java.lang.arrayindexoutofboundsexception
这个异常相信很多朋友也经常遇到过，异常的解释是"数组下标越界"，现在程序中大多都有对数组的操作，因此在调用数组的时候一定要认真检查，看自己调用的下标是不是超出了数组的范围，一般来说，显示（即直接用常数当下标）调用不太容易出这样的错，但隐式（即用变量表示下标）调用就经常出错了，还有一种情况，是程序中定义的数组的长度是通过某些特定方法决定的，不是事先声明的，这个时候，最好先查看一下数组的length，以免出现这个异常。

5. java.lang.illegalargumentexception
这个异常的解释是"方法的参数错误"，很多j2me的类库中的方法在一些情况下都会引发这样的错误，比如音量调节方法中的音量参数如果写成负数就会出现这个异常，再比如g.setcolor(int red,int green,int blue)这个方法中的三个值，如果有超过255的也会出现这个异常，因此一旦发现这个异常，我们要做的，就是赶紧去检查一下方法调用中的参数传递是不是出现了错误。

6. java.lang.illegalaccessexception
这个异常的解释是"没有访问权限"，当应用程序要调用一个类，但当前的方法即没有对该类的访问权限便会出现这个异常。对程序中用了package的情况下要注意这个异常。

其他还有很多异常，我就不一一列举了，我要说明的是，一个合格的程序员，需要对程序中常见的问题有相当的了解和相应的解决办法，否则仅仅停留在写程序而不会改程序的话，会极大影响到自己的开发的。关于异常的全部说明，在api里都可以查阅。

算术异常类：ArithmeticExecption

空指针异常类：NullPointerException

类型强制转换异常：ClassCastException

数组负下标异常：NegativeArrayException

数组下标越界异常：ArrayIndexOutOfBoundsException

违背安全原则异常：SecturityException

文件已结束异常：EOFException

文件未找到异常：FileNotFoundException

字符串转换为数字异常：NumberFormatException

操作数据库异常：SQLException

输入输出异常：IOException

方法未找到异常：NoSuchMethodException

java.lang.AbstractMethodError

抽象方法错误。当应用试图调用抽象方法时抛出。

java.lang.AssertionError

断言错。用来指示一个断言失败的情况。

java.lang.ClassCircularityError

类循环依赖错误。在初始化一个类时，若检测到类之间循环依赖则抛出该异常。

java.lang.ClassFormatError

类格式错误。当Java虚拟机试图从一个文件中读取Java类，而检测到该文件的内容不符合类的有效格式时抛出。

java.lang.Error

错误。是所有错误的基类，用于标识严重的程序运行问题。这些问题通常描述一些不应被应用程序捕获的反常情况。

java.lang.ExceptionInInitializerError

初始化程序错误。当执行一个类的静态初始化程序的过程中，发生了异常时抛出。静态初始化程序是指直接包含于类中的static语句段。

java.lang.IllegalAccessError

违法访问错误。当一个应用试图访问、修改某个类的域（Field）或者调用其方法，但是又违反域或方法的可见性声明，则抛出该异常。

java.lang.IncompatibleClassChangeError

不兼容的类变化错误。当正在执行的方法所依赖的类定义发生了不兼容的改变时，抛出该异常。一般在修改了应用中的某些类的声明定义而没有对整个应用重新编译而直接运行的情况下，容易引发该错误。

java.lang.InstantiationError

实例化错误。当一个应用试图通过Java的new操作符构造一个抽象类或者接口时抛出该异常.

java.lang.InternalError

内部错误。用于指示Java虚拟机发生了内部错误。

java.lang.LinkageError

链接错误。该错误及其所有子类指示某个类依赖于另外一些类，在该类编译之后，被依赖的类改变了其类定义而没有重新编译所有的类，进而引发错误的情况。

java.lang.NoClassDefFoundError

未找到类定义错误。当Java虚拟机或者类装载器试图实例化某个类，而找不到该类的定义时抛出该错误。

java.lang.NoSuchFieldError

域不存在错误。当应用试图访问或者修改某类的某个域，而该类的定义中没有该域的定义时抛出该错误。

java.lang.NoSuchMethodError

方法不存在错误。当应用试图调用某类的某个方法，而该类的定义中没有该方法的定义时抛出该错误。

java.lang.OutOfMemoryError

内存不足错误。当可用内存不足以让Java虚拟机分配给一个对象时抛出该错误。

java.lang.StackOverflowError

堆栈溢出错误。当一个应用递归调用的层次太深而导致堆栈溢出时抛出该错误。

java.lang.ThreadDeath

线程结束。当调用Thread类的stop方法时抛出该错误，用于指示线程结束。

java.lang.UnknownError

未知错误。用于指示Java虚拟机发生了未知严重错误的情况。

java.lang.UnsatisfiedLinkError

未满足的链接错误。当Java虚拟机未找到某个类的声明为native方法的本机语言定义时抛出。

java.lang.UnsupportedClassVersionError

不支持的类版本错误。当Java虚拟机试图从读取某个类文件，但是发现该文件的主、次版本号不被当前Java虚拟机支持的时候，抛出该错误。

java.lang.VerifyError

验证错误。当验证器检测到某个类文件中存在内部不兼容或者安全问题时抛出该错误。

java.lang.VirtualMachineError

虚拟机错误。用于指示虚拟机被破坏或者继续执行操作所需的资源不足的情况。

java.lang.ArithmeticException

算术条件异常。譬如：整数除零等。

java.lang.ArrayIndexOutOfBoundsException

数组索引越界异常。当对数组的索引值为负数或大于等于数组大小时抛出。

java.lang.ArrayStoreException

数组存储异常。当向数组中存放非数组声明类型对象时抛出。

java.lang.ClassCastException

类造型异常。假设有类A和B（A不是B的父类或子类），O是A的实例，那么当强制将O构造为类B的实例时抛出该异常。该异常经常被称为强制类型转换异常。

java.lang.ClassNotFoundException

找不到类异常。当应用试图根据字符串形式的类名构造类，而在遍历CLASSPAH之后找不到对应名称的class文件时，抛出该异常。

java.lang.CloneNotSupportedException

不支持克隆异常。当没有实现Cloneable接口或者不支持克隆方法时,调用其clone()方法则抛出该异常。

java.lang.EnumConstantNotPresentException

枚举常量不存在异常。当应用试图通过名称和枚举类型访问一个枚举对象，但该枚举对象并不包含常量时，抛出该异常。

java.lang.Exception

根异常。用以描述应用程序希望捕获的情况。

java.lang.IllegalAccessException

违法的访问异常。当应用试图通过反射方式创建某个类的实例、访问该类属性、调用该类方法，而当时又无法访问类的、属性的、方法的或构造方法的定义时抛出该异常。

java.lang.IllegalMonitorStateException

违法的监控状态异常。当某个线程试图等待一个自己并不拥有的对象（O）的监控器或者通知其他线程等待该对象（O）的监控器时，抛出该异常。

java.lang.IllegalStateException

违法的状态异常。当在Java环境和应用尚未处于某个方法的合法调用状态，而调用了该方法时，抛出该异常。

java.lang.IllegalThreadStateException

违法的线程状态异常。当县城尚未处于某个方法的合法调用状态，而调用了该方法时，抛出异常。

java.lang.IndexOutOfBoundsException

索引越界异常。当访问某个序列的索引值小于0或大于等于序列大小时，抛出该异常。

java.lang.InstantiationException

实例化异常。当试图通过newInstance()方法创建某个类的实例，而该类是一个抽象类或接口时，抛出该异常。

java.lang.InterruptedException

被中止异常。当某个线程处于长时间的等待、休眠或其他暂停状态，而此时其他的线程通过Thread的interrupt方法终止该线程时抛出该异常。

java.lang.NegativeArraySizeException

数组大小为负值异常。当使用负数大小值创建数组时抛出该异常。

java.lang.NoSuchFieldException

属性不存在异常。当访问某个类的不存在的属性时抛出该异常。

java.lang.NoSuchMethodException

方法不存在异常。当访问某个类的不存在的方法时抛出该异常。

java.lang.NullPointerException

空指针异常。当应用试图在要求使用对象的地方使用了null时，抛出该异常。譬如：调用null对象的实例方法、访问null对象的属性、计算null对象的长度、使用throw语句抛出null等等。

java.lang.NumberFormatException

数字格式异常。当试图将一个String转换为指定的数字类型，而该字符串确不满足数字类型要求的格式时，抛出该异常。

java.lang.RuntimeException

运行时异常。是所有Java虚拟机正常操作期间可以被抛出的异常的父类。

java.lang.SecurityException

安全异常。由安全管理器抛出，用于指示违反安全情况的异常。

java.lang.StringIndexOutOfBoundsException

字符串索引越界异常。当使用索引值访问某个字符串中的字符，而该索引值小于0或大于等于序列大小时，抛出该异常。

java.lang.TypeNotPresentException

类型不存在异常

3. 求救，分布式事务怎么处理

1.性能和时延问题在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗：1）客户端需要对消息进行序列化，主要占用CPU计算资源。2）序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。3）客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。4）服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。5）服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。6）服务端将响应结果序列化，占用CPU计算资源。7）服务端将应答码流发送给客户端，占用网络带宽资源。8）客户端读取应答码流，反序列化成响应消息，占用CPU资源。通过分析我们发现，一个简单的本地方法调用，切换成远程服务调用之后，额外增加了很多处理流程，不仅占用大量的系统资源，同时增加了时延。一些复杂的应用会拆分成多个服务，形成服务调用链，如果服务化框架的性能比较差、服务调用时延也比较大，业务服务化之后的性能和时延将无法满足业务的性能需求。1.1　RPC框架高性能设计影响RPC框架性能的主要因素有三个。1）I/O调度模型：同步阻塞I/O（BIO）还是非阻塞I/O（NIO）。2）序列化框架的选择：文本协议、二进制协议或压缩二进制协议。3）线程调度模型：串行调度还是并行调度，锁竞争还是无锁化算法。1.I/O调度模型在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。JDK1.5_update10版本使用epoll替代了传统的select/poll，极大地提升了NIO通信的性能，它的工作原理如图1-1所示。图1-1　非阻塞I/O工作原理Netty是一个开源的高性能NIO通信框架：它的I/O线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成百上千个客户端Channel。由于读写操作都是非阻塞的，这就可以充分提升I/O线程的运行效率，避免由于频繁I/O阻塞导致的线程挂起。另外，由于Netty采用了异步通信模式，一个I/O线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻塞I/O一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。Netty被精心设计，提供了很多独特的性能提升特性，使它做到了在各种NIO框架中性能排名第一，它的性能优化措施总结如下。1）零拷贝：（1）Netty的接收和发送ByteBuffer采用DIRECTBUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAPBUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。（2）Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便地对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。（3）Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。2）内存池：随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。3）无锁化的串行设计：在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导致性能的下降。为了尽可能地避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多线程竞争和同步锁。为了尽可能提升性能，Netty采用了串行无锁化设计，在I/O线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列-多个工作线程模型性能更优。4）高效的并发编程：volatile的大量、正确使用；CAS和原子类的广泛使用；线程安全容器的使用；通过读写锁提升并发性能。2.高性能序列化框架影响序列化性能的关键因素总结如下。1）序列化后的码流大小（网络带宽的占用）。2）序列化&反序列化的性能（CPU资源占用）。3）是否支持跨语言（异构系统的对接和开发语言切换）。4）并发调用的性能表现：稳定性、线性增长、偶现的时延毛刺等。相比于JSON等文本协议，二进制序列化框架性能更优异，以Java原生序列化和Protobuf二进制序列化为例进行性能测试对比，结果如图1-2所示。图1-2　序列化性能测试对比数据在序列化框架的技术选型中，如无特殊要求，尽量选择性能更优的二进制序列化框架，码流是否压缩，则需要根据通信内容做灵活选择，对于图片、音频、有大量重复内容的文本文件（例如小说）可以采用码流压缩，常用的压缩算法包括GZip、Zig-Zag等。3.高性能的Reactor线程模型该模型的特点总结如下。1）有专门一个NIO线程：Acceptor线程用于监听服务端，接收客户端的TCP连接请求。2）网络I/O操作：读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送。3）1个NIO线程可以同时处理N条链路，但是1个链路只对应1个NIO线程，防止产生并发操作。由于Reactor模式使用的是异步非阻塞I/O，所有的I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有I/O相关的操作，因此在绝大多数场景下，Reactor多线程模型都可以完全满足业务性能需求。Reactor线程调度模型的工作原理示意如图1-3所示。图1-3　高性能的Reactor线程调度模型1.2　业务最佳实践要保证高性能，单依靠分布式服务框架是不够的，还需要应用的配合，应用服务化高性能实践总结如下：1）能异步的尽可能使用异步或者并行服务调用，提升服务的吞吐量，有效降低服务调用时延。2）无论是NIO通信框架的线程池还是后端业务线程池，线程参数的配置必须合理。如果采用JDK默认的线程池，最大线程数建议不超过20个。因为JDK的线程池默认采用N个线程争用1个同步阻塞队列方式，当线程数过大时，会导致激烈的锁竞争，此时性能不仅不会提升，反而会下降。3）尽量减小要传输的码流大小，提升性能。本地调用时，由于在同一块堆内存中访问，参数大小对性能没有任何影响。跨进程通信时，往往传递的是个复杂对象，如果明确对方只使用其中的某几个字段或者某个对象引用，则不要把整个复杂对象都传递过去。举例，对象A持有8个基本类型的字段，2个复杂对象B和C。如果明确服务提供者只需要用到A聚合的C对象，则请求参数应该是C，而不是整个对象A。4）设置合适的客户端超时时间，防止业务高峰期因为服务端响应慢导致业务线程等应答时被阻塞，进而引起后续其他服务的消息在队列中排队，造成故障扩散。5）对于重要的服务，可以单独部署到独立的服务线程池中，与其他非核心服务做隔离，保障核心服务的高效运行。6）利用Docker等轻量级OS容器部署服务，对服务做物理资源层隔离，避免虚拟化之后导致的超过20%的性能损耗。7）设置合理的服务调度优先级，并根据线上性能监控数据做实时调整。2.事务一致性问题服务化之前，业务采用本地事务，多个本地SQL调用可以用一个大的事务块封装起来，如果某一个数据库操作发生异常，就可以将之前的SQL操作进行回滚，只有所有SQL操作全部成功，才最终提交，这就保证了事务强一致性，如图2-1所示。服务化之后，三个数据库操作可能被拆分到独立的三个数据库访问服务中，此时原来的本地SQL调用演变成了远程服务调用，事务一致性无法得到保证，如图2-2所示。图2-2　服务化之后引入分布式事务问题假如服务A和服务B调用成功，则A和B的SQL将会被提交，最后执行服务C，它的SQL操作失败，对于应用1消费者而言，服务A和服务B的相关SQL操作已经提交，服务C发生了回滚，这就导致事务不一致。从图2-2可以得知，服务化之后事务不一致主要是由服务分布式部署导致的，因此也被称为分布式事务问题。2.1　分布式事务设计方案通常，分布式事务基于两阶段提交实现，它的工作原理示意图如图2-3所示。图2-3　两阶段提交原理图阶段1：全局事务管理器向所有事务参与者发送准备请求；事务参与者向全局事务管理器回复自己是否准备就绪。阶段2：全局事务管理器接收到所有事务参与者的回复之后做判断，如果所有事务参与者都可以提交，则向所有事务提交者发送提交申请，否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚操作。分布式事务回滚原理图如图2-4所示。图2-4　分布式事务回滚原理图两阶段提交采用的是悲观锁策略，由于各个事务参与者需要等待响应最慢的参与者，因此性能比较差。第一个问题是协议本身的成本：整个协议过程是需要加锁的，比如锁住数据库的某条记录，且需要持久化大量事务状态相关的操作日志。更为麻烦的是，两阶段锁在出现故障时表现出来的脆弱性，比如两阶段锁的致命缺陷：当协调者出现故障，整个事务需要等到协调者恢复后才能继续执行，如果协调者出现类似磁盘故障等错误，该事务将被永久遗弃。对于分布式服务框架而言，从功能特性上需要支持分布式事务。在实际业务使用过程中，如果能够通过最终一致性解决问题，则不需要做强一致性；如果能够避免分布式事务，则尽量在业务层避免使用分布式事务。2.2　分布式事务优化既然分布式事务有诸多缺点，那么为什么我们还在使用呢？有没有更好的解决方案来改进或者替换呢？如果我们只是针对分布式事务去优化的话，发现其实能改进的空间很小，毕竟瓶颈在分布式事务模型本身。那我们回到问题的根源：为什么我们需要分布式事务？因为我们需要各个资源数据保持一致性，但是对于分布式事务提供的强一致性，所有业务场景真的都需要吗？大多数业务场景都能容忍短暂的不一致，不同的业务对不一致的容忍时间不同。像银行转账业务，中间有几分钟的不一致时间，用户通常都是可以理解和容忍的。在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性，尽量避免使用分布式事务。在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色，它的工作原理如下：在做本地事务之前，先向MQ发送一个prepare消息，然后执行本地事务，本地事务提交成功的话，向MQ发送一个commit消息，否则发送一个rollback消息，取消之前的消息。MQ只会在收到commit确认才会将消息投递出去，所以这样的形式可以保证在一切正常的情况下，本地事务和MQ可以达到一致性。但是分布式调用存在很多异常场景，诸如网络超时、VM宕机等。假如系统执行了local_tx()成功之后，还没来得及将commit消息发送给MQ，或者说发送出去由于网络超时等原因，MQ没有收到commit，发生了commit消息丢失，那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问（回调）发消息的系统（checkCommit）进行检查该消息是否应该投递出去或者丢弃，得到系统的确认之后，MQ会做投递还是丢弃，这样就完全保证了MQ和发消息的系统的一致性，从而保证了接收消息系统的一致性。3.研发团队协作问题服务化之后，特别是采用微服务架构以后。研发团队会被拆分成多个服务化小组，例如AWS的TwoPizzaTeam，每个团队由2~3名研发负责服务的开发、测试、部署上线、运维和运营等。随着服务数的膨胀，研发团队的增多，跨团队的协同配合将会成为一个制约研发效率提升的因素。3.1　共用服务注册中心为了方便开发测试，经常会在线下共用一个所有服务共享的服务注册中心，这时，一个正在开发中的服务发布到服务注册中心，可能会导致一些消费者不可用。解决方案：可以让服务提供者开发方，只订阅服务（开发的服务可能依赖其他服务），而不注册正在开发的服务，通过直连测试正在开发的服务。它的工作原理如图3-1所示。图3-1　只订阅，不发布3.2　直连提供者在开发和测试环境下，如果公共的服务注册中心没有搭建，消费者将无法获取服务提供者的地址列表，只能做本地单元测试或使用模拟桩测试。还有一种场景就是在实际测试中，服务提供者往往多实例部署，如果服务提供者存在Bug，就需要做远程断点调试，这会带来两个问题：1）服务提供者多实例部署，远程调试地址无法确定，调试效率低下。2）多个消费者可能共用一套测试联调环境，断点调试过程中可能被其他消费者意外打断。解决策略：绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式将以服务接口为单位，忽略注册中心的提供者列表。3.3　多团队进度协同假如前端Web门户依赖后台A、B、C和D4个服务，分别由4个不同的研发团队负责，门户要求新特性2周内上线。A和B内部需求优先级排序将门户的优先级排的比较高，可以满足交付时间点。但是C和D服务所在团队由于同时需要开发其他优先级更高的服务，因此把优先级排的相对较低，无法满足2周交付。在C和D提供版本之前，门户只能先通过打测试桩的方式完成Mock测试，但是由于并没有真实的测试过C和D服务，因此需求无法按期交付。应用依赖的服务越多，特性交付效率就越低下，交付的速度取决于依赖的最迟交付的那个服务。假如Web门户依赖后台的100个服务，只要1个核心服务没有按期交付，则整个进度就会延迟。解决方案：调用链可以将应用、服务和中间件之间的依赖关系串接并展示出来，基于调用链首入口的交付日期作为输入，利用依赖管理工具，可以自动计算出调用链上各个服务的最迟交付时间点。通过调用链分析和标准化的依赖计算工具，可以避免人为需求排序失误导致的需求延期。3.4　服务降级和Mock测试在实际项目开发中，由于小组之间、个人开发者之间开发节奏不一致，经常会出现消费者等待依赖的服务提供者提供联调版本的情况，相互等待会降低项目的研发进度。解决方案：服务提供者首先将接口定下来并提供给消费者，消费者可以将服务降级同Mock测试结合起来，在Mock测试代码中实现容错降级的业务逻辑（业务放通），这样既完成了Mock测试，又实现了服务降级的业务逻辑开发，一举两得。3.5　协同调试问题在实际项目开发过程中，各研发团队进度不一致很正常。如果消费者坐等服务提供者按时提供版本，往往会造成人力资源浪费，影响项目进度。解决方案：分布式服务框架提供Mock桩管理框架，当周边服务提供者尚未完成开发时，将路由切换到模拟测试模式，自动调用Mock桩；业务集成测试和上线时，则要能够自动切换到真实的服务提供者上，可以结合服务降级功能实现。3.6　接口前向兼容性由于线上的Bug修复、内部重构和需求变更，服务提供者会经常修改内部实现，包括但不限于：接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。在实际项目中经常会发生服务提供者修改了接口或者数据结构，但是并没有及时知会到所有消费者，导致服务调用失败。解决方案：1）制定并严格执行《服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。2）接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段定义位置无关性，码流支持乱序等。4.总结服务化之后，无论是服务化框架，还是业务服务，都面临诸多挑战，本章摘取了其中一些比较重要的问题，并给出解决方案和最佳实践。对于本章节没有列出的问题，则需要服务框架开发者和使用者在实践中探索，找出一条适合自己产品的服务化最佳实践。

4. oledb 提供程序'SQL OLEDB'无法启动分布式事务 是什么错误

在开发分布式数据库软件时，经常碰到下面的错误：
服务器: 消息 7391，级别 16，状态 1，行 6
该操作未能执行，因为 OLE DB 提供程序 'SQLOLEDB' 无法启动分
布式事务。
[OLE/DB provider returned message: 不能在指定的事务处理器中
获得新事务。]
---------------------------------------------------------------------------------------------
服务器: 消息 8520，级别 20，状态 1，行 8
内部 MSDTC 事务的提交失败: Result Code = 0x8004d019。

连接中断
---------------------------------------------------------------------------------------------

搜索了网上类似问题的解决方案，都建议采用下面的方法（方法一）：
1、运行 regedt32，浏览至 HKEY_LOCAL_MACHINE oftware/Microsoft/MSDTC。
添加一个 DWORD 值 TurnOffRpcSecurity，值数据为 1。
2、重启MS DTC服务。
3、打开“管理工具”的“组件服务”。
    a. 浏览至"启动管理工具"。    b. 选择"组件服务"。    c. 展开"组件服务"树，然后展开"我的电脑"。    d. 右键单击"我的电脑"，然后选择"属性"。     在 MSDTC 选项卡中，确保选中了下列选项： 
网络 DTC 访问 网络管理 网络事务XA 事务
另外，"DTC 登录帐户"一定要设置为"NT Authority/NetworkService"。4、重启MS DTC服务。
5、再次运行 regedt32，浏览至 HKEY_LOCAL_MACHINE oftware/Microsoft/MSDTC，然后删除 TurnOffRpcSecurity 项。

但是实际上该方法基本上解决不了问题，经过长时间的反复实践，我终于按下面的方法解决了：
（方法二）
1、按照方法一的方法处理一遍，如果不行，再继续下面的方法
2、安装windows 2003 sp1，安装好后，方法一中的第4步设置对话框和原来不一样了，选择“事务管理通讯”中的“不要求验证”
3、最好安装好MDAC2.8

4、安装netbios协议
5、通过查找，在C:找到名为“hosts”的文件（没有扩展名），通常路径为C:/WINDOWS/system32/drivers/etc，将对方服务器的IP和计算机对应起来，

5. 开启了事务，在sql出错的时候不执行commit，也没执行rollback的话，会出现什么情况？

有可能出现死锁。
因为在对表做更新操作的时候，就会在表上加锁，事务没提交，锁是不会释放的，这是数据库为了保证数据完整性的操作。那么在某个程序写数据库表的时候，其他任何程序对该表是无法进行读取和写入的，处于等待状态。
如果出现了循环等待，A等B，B等C，C等A那么就出现了死锁。

6. 如何在SQL存储过程中处理错误

一、存储过程中使用事务的简单语法
在存储过程中使用事务时非常重要的，使用数据可以保持数据的关联完整性，在Sql server存储过程中使用事务也很简单，用一个例子来说明它的语法格式： 
Create Procedure  MyProcedure    (   @Param1       nvarchar(10),       @param2    nvarchar(10)    )    AS       BeginSet NOCOUNT ON;           Set XACT_ABORT ON;           Begin  Tran              Delete from       table1 where name=’abc’;              Insert into       table2 values(value1,value2,value3);           Commit Tran       End说明：
1 、使用存储过程执行事物，需要开启XACT_ABORT参数(默认值为Off)，将该参数设置为On，表示当执行事务时，如果出错,会将transcation设置为uncommittable状态，那么在语句块批处理结束后将回滚所有操作；如果该参数设置为Off，表示当执行事务时，如果出错，出错的语句将不会执行，其他正确的操作继续执行。

2、当SET NOCOUNT 为 ON 时，不返回计数（计数表示受 Transact-SQL 语句影响的行数，例如在Sql server查询分析器中执行一个delete操作后，下方窗口会提示（3）Rows Affected）。当 SET NOCOUNT 为 OFF 时，返回计数,我们应该在存储过程的头部加上SET NOCOUNT ON 这样的话，在退出存储过程的时候加上 SET NOCOUNT OFF这样的话，以达到优化存储过程的目的。
  
二、事务内设置保存点
　　用户可以在事务内设置保存点或标记。保存点定义如果有条件地取消事务的一部分，事务可以返回的位置。如果将事务回滚到保存点，则必须（如果需要，使用更多的 Transact-SQL 语句和 COMMIT TRANSACTION 语句）继续完成事务，或者必须（通过将事务回滚到其起始点）完全取消事务。若要取消整个事务，请使用 ROLLBACK TRANSACTION transaction_name 格式。这将撤消事务的所有语句和过程。如：
代码
Create Procedure  MyProcedureAS    Begin           Set    NOCOUNT    ON;           Set XACT_ABORT ON;                      begin   tran  ok  --开始一个事务OK               delete  from  rxqz  where qz=   'rx015 ' --删除数据             save   tran  bcd   --保存一个事务点命名为bcd              update  sz  set   name='李丽s' where name= '李丽'--修改数据            if  @@error0  --判断修改数据有没有出错                 begin --如果出错                        rollback   tran  bcd  -- 回滚事务到BCD 的还原点                    commit   tran  ok  --提交事务                     end               else  --没有出错                commit  tran ok --提交事务       End说明：1、@@error判断是否有错误，为0表示没有错误，但是对那种重大错误无法捕捉，而且@@error只能前一句sql语句生效。
  
三、存储过程使用try…catch捕获错误
　　在存储过程中可以使用try…catch语句来捕获错误，如下：  
Create Procedure  MyProcedure    (   @Param1       nvarchar(10),       @param2    nvarchar(10)    )    AS       Begin           Set    NOCOUNT    ON;           Begin  try              Delete from       table1 where name=’abc’;              Insert into       table2 values(value1,value2,value3);           End    try           Begin  Catch                  SELECT ERROR_NUMBER()  AS  ErrorNumber,                       ERROR_MESSAGE()  AS  ErrorMessage;           End    Catch    End 
说明：1、捕获错误的函数有很多，如下：
ERROR_NUMBER() 返回错误号。
　　　　ERROR_SEVERITY() 返回严重性。
　　　　ERROR_STATE() 返回错误状态号。
　　　　ERROR_PROCEDURE() 返回出现错误的存储过程或触发器的名称。
　　　　ERROR_LINE() 返回导致错误的例程中的行号。
　　　　ERROR_MESSAGE() 返回错误消息的完整文本。该文本可包括任何可替换参数所提供的值，如长度、对象名或时间。
　　　　2、有些错误，如sql语句中的表名称输入错误，这是数据库引擎无法解析这个表名称时，所发生的错误在当前的try…catch语句中无法捕获，必须由外层调用该存储过程的地方使用　　　　　　　　　　　　 try…catch来进行捕获。
 
 
四、存储过程中事务和try…catch联合使用 
在存储过程中使用事务时，如果没有try…catch语句，那么当set xact_abort on时，如果有错误发生，在批处理语句结束后，系统会自动回滚所有的sql操作。当set xact_abort off时，如果有错误发生，在批处理语句结束后，系统会执行所有没有发生错误的语句，发生错误的语句将不会被执行。
在存储过程中使用事务时，如果存在try…catch语句块，那么当捕获到错误时，需要在catch语句块中手动进行Rollback操作，否则系统会给客户端传递一条错误信息。如果在存储过程开始处将set xact_abort on，那么当有错误发生时，系统会将当前事务置为不可提交状态，即会将xact_state()置为-1，此时只可以对事务进行Rollback操作，不可进行提交(commit)操作，那么我们在catch语句块中就可以根据xact_state()的值来判断是否有事务处于不可提交状态，如果有则可以进行rollback操作了。如果在存储过程开始处将set xact_abort off，那么当有错误发生时，系统不会讲xact_state()置为-1，那么我们在catch块中就不可以根据该函数值来判断是否需要进行rollback了，但是我们可以根据@@Trancount全局变量来判断，如果在catch块中判断出@@Trancount数值大于0，代表还有未提交的事务，既然进入catch语句块了，那么还存在未提交的事务，该事务应该是需要rollback的，但是这种方法在某些情况下可能判断的不准确。推荐的方法还是将set xact_abort on，然后在catch中判断xact_state()的值来判断是否需要Rollback操作。
下面我们来看看两个例子： 
一．使用Set xact_abort on
 
Create  proc  myProcedureAs    begin       set xact_abort on;       begin try           begin tran              insert into TestStu values('Terry','boy',23);              insert into TestStu values('Mary','girl',21);           commit tran       end try       begin catch           --在此可以使用xact_state()来判断是否有不可提交的事务,不可提交的事务           --表示在事务内部发生错误了。Xact_state()有三种值：-1.事务不可提交；           --1.事务可提交；0.表示没有事务，此时commit或者rollback会报错。           if xact_state()=-1              rollback tran;       end catchend 
二.使用Set xact_abort off
Create  proc  myProcedureAs    begin       set xact_abort off;       begin try           begin tran              insert into TestStu values('Terry','boy',23);              insert into TestStu values('Mary','girl',21);           commit tran       end try       begin catch           --在此不可以使用xact_state来判断是否有不可提交的事务           --只可以使用@@Trancount来判断是否有还未提交的事务，未提交的事务未必           --就是不可提交的事务，所以使用@@TranCount>0后就RollBack是不准确的           if @@TranCount>0              rollback tran;       end catchend另外，对于@@Trancount需要说明的是，begin tran 语句将 @@Trancount加 1。Rollback tran将 @@Trancount递减到 0，但 Rollback tran savepoint_name 除外，它不影响 @@Trancount。Commit tran 或 Commit work 将 @@Trancount 递减 1。

7. Access 当一个过程执行后产生了错误,则撤销该过程中所有已经产生的更改，求代码

这是一个典型的事务需求。
 
ACCESS数据库本身没有事务功能，但是使用ADO数据访问类库的Connetion对象的事务处理方法(BeginTrans\ComitTrans\RollbackTrans）能够实现对ACCESS数据库的一系列数据操作，要么全部成功，要么全部失败（也就是所谓“事务”），借以保证ACCESS数据库中的数据始终处于正确状态。
 
下面是VB操纵ACCESS数据库实现错误回滚的示例代码，供参考。这些代码本人在实际开发的程序中用过，其效果已得到验证：
 
首先要引用ADO类库，具体方法略。。。
 
Sub Proc1 ()
On Error GoTo ErrorHandler
 
Dim cn As New ADODB.Connection  '声明并实例化ADO连接对象
Dim cnStr As String
Dim strSql As String
 
cnStr = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & App.Path & "\MyAccess.mdb;Persist Security Info=False;"
cn.Open cnStr  '打开与数据库的连接,实际连接字符串请根据具体情况调整
 
cn.BeginTrans   '开始事务处理
 
'数据更改1
'例如修改表1某条记录
strSql = "update table1 set col1=500 where ID='001'"  '
cn.Execute strSql    '执行该SQL更新查询语句
 
'数据更改2
'例如删除表2某条记录
strSql = "delete from table2 where SID='F4561'"
cn.Execute strSql    '执行该SQL删除查询语句
 
'数据更改3
'例如将表3的价格字段值增加10%
strSql = "update table3 set price=price*1.1"
cn.Execute strSql    '执行该SQL更新查询语句

cn.CommitTrans      '提交事务
MsgBox "数据系列性（事务）修改成功"   '提示全部操作成功

ErrorHandler:   '错误处理程序
' 释放连接对象
If Not cn Is Nothing Then
If cn.State = adStateOpen Then cn.Close
End If
Set cn = Nothing
If Err.Number  0 Then MsgBox Err.Number & " " & Err.Description   '提示错误原因
 
 end sub
 
这样如果代码中的任何一个数据操作失败的话，所有已经执行的变更都会自动取消（执行RollbackTrans）。楼主可以测试一下。

8. spring 事务问题 HibernateTemplate执行修改操作，提示对象是只读状态，急急急急急！！！！！！！！！

原因是DAO采用了Spring容器的事务管理策略，如果操作方法的名称和事务策略中指定的被管理的名称不能被匹配上，spring 就会自动采取默认的事务管理策略(PROPAGATION_REQUIRED,read only)。如果是插入和修改操作，就不会被允许的，所以会报这种异常。
HibernateTemplateHibernateTemplate是简单易用一种函数，功能是将Hibernate 的持久层访问模板化，创建HibernateTemplate 实例后，注入一个SessionFactory 的引用，就可执行持久化操作。
使用HibernateTemplate
HibernateTemplate 可将Hibernate 的持久层访问模板化，使用HibernateTemplate 非常简单。创建HibernateTemplate 实例后，注入一个SessionFactory 的引用，就可执行持久化操作。SessionFactory 对象可通过构造参数传入，或通过设值方式传入。例如:
//获取Spring 上下文
ApplicationContext ctx = new FileSystemXmlApplicationContext("bean.xml");
//
SessionFactory sessionFactory = (SessionFactory) ctx.getBean("sessionFactory") ,
HibernateTemplate 提供如下三个构造函数:
· HibernateTemplate() 。
· HibernateTemplate(org.hibernate.SessionFactory sessionFactory)。
· HibernateTemplate(org.hibernate.SessionFactory sessionFactory, boolean allowCreate) 。
第一个构造函数:构造一个默认的HibernateTemplate 实例，因此，使用HibernateTemplate实例之前，还必须使用方法setSessionFactory(SessionFactory sessionFactory)来为HibernateTemplate 传入SessionFactory 的引用。
第二个构造函数:在构造时已经传入SessionFactory 引用。
第三个构造函数:其boolean 型参数表明，如果当前线程己经存在一个非事务性的Session ，是否直接返回此非事务性的Session 。
对于在Web 应用中，通常启动时自动加载ApplicationContext ，SessionFactory 和DAO对象都处在Spring 上下文管理下。因此无须在代码中显式设置，可采用依赖注入解耦SessionFactory 和DAO。其依赖关系可通过配置文件来设置。