- 浏览: 1024511 次
- 性别:
- 来自: 杭州
-
文章分类
- 全部博客 (826)
- 硬件 (8)
- 软件 (24)
- 软件工程 (34)
- JAVA (229)
- C/C++/C# (77)
- JavaScript (8)
- PHP (1)
- Ruby (3)
- MySQL (14)
- 数据库 (19)
- 心情记事 (12)
- 团队管理 (19)
- Hadoop (1)
- spring (22)
- mybatis(ibatis) (7)
- tomcat (16)
- velocity (0)
- 系统架构 (6)
- JMX (8)
- proxool (1)
- 开发工具 (16)
- python (10)
- JVM (27)
- servlet (5)
- JMS (26)
- ant (2)
- 设计模式 (5)
- 智力题 (2)
- 面试题收集 (1)
- 孙子兵法 (16)
- 测试 (1)
- 数据结构 (7)
- 算法 (22)
- Android (11)
- 汽车驾驶 (1)
- lucene (1)
- memcache (12)
- 技术架构 (7)
- OTP-Erlang (7)
- memcached (17)
- redis (20)
- 浏览器插件 (3)
- sqlite (3)
- Heritrix (9)
- Java线程 (1)
- scala (0)
- Mina (6)
- 汇编 (2)
- Netty (15)
- libevent (0)
- CentOS (12)
- mongod (5)
- mac os (0)
最新评论
-
kingasdfg:
你这里面存在一个错误添加多个任务 应该是这样的 /** * ...
Quartz的任务的临时启动和暂停和恢复【转】 -
kyzeng:
纠正一个错误,long型对应的符号是J,不是L。
Jni中C++和Java的参数传递 -
zhaohaolin:
抱歉,兄弟,只是留下作记录,方便学习,如果觉得资料不好,可以到 ...
netty的个人使用心得【转】 -
cccoooccooco:
谢谢!自己一直以为虚机得使用网线才可以与主机连接呢。。
主机网卡无网线连接与虚拟机通信 -
yuqilin001:
要转别人的东西,请转清楚点嘛,少了这么多类,误人子弟
netty的个人使用心得【转】
在所有使用 spring 的应用中, 声明式事务管理可能是使用率最高的功能了, 但是, 从我观察到的情况看,
绝大多数人并不能深刻理解事务声明中不同事务传播属性配置的的含义, 让我们来看一下 TransactionDefinition 接口中的定义
- int PROPAGATION_REQUIRED = 0 ;
- int PROPAGATION_SUPPORTS = 1 ;
- int PROPAGATION_MANDATORY = 2 ;
- int PROPAGATION_REQUIRES_NEW = 3 ;
- int PROPAGATION_NOT_SUPPORTED = 4 ;
- int PROPAGATION_NEVER = 5 ;
- int PROPAGATION_NESTED = 6 ;
我们可以看到, 在 spring 中一共定义了六种事务传播属性, 如果你觉得看起来不够直观, 那么我来转贴一个满大街都有的翻译
PROPAGATION_REQUIRED -- 支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择。
PROPAGATION_SUPPORTS -- 支持当前事务,如果当前没有事务,就以非事务方式执行。
PROPAGATION_MANDATORY -- 支持当前事务,如果当前没有事务,就抛出异常。
PROPAGATION_REQUIRES_NEW -- 新建事务,如果当前存在事务,把当前事务挂起。
PROPAGATION_NOT_SUPPORTED -- 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
PROPAGATION_NEVER -- 以非事务方式执行,如果当前存在事务,则抛出异常。
PROPAGATION_NESTED -- 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则进行与PROPAGATION_REQUIRED类似的操作。
前六个策略类似于EJB CMT,第七个(PROPAGATION_NESTED)是Spring所提供的一个特殊变量。
它要求事务管理器或者使用JDBC 3.0 Savepoint API提供嵌套事务行为(如Spring的DataSourceTransactionManager)
在我所见过的误解中, 最常见的是下面这种:
假如有两个业务接口 ServiceA 和 ServiceB, 其中 ServiceA 中有一个方法实现如下
/**
* 事务属性配置为 PROPAGATION_REQUIRED
*/
void methodA() {
// 调用 ServiceB 的方法
ServiceB.methodB();
}
那么如果 ServiceB 的 methodB 如果配置了事务, 就必须配置为 PROPAGATION_NESTED
这种想法可能害了不少人, 认为 Service 之间应该避免互相调用, 其实根本不用担心这点,PROPAGATION_REQUIRED 已经说得很明白,
如
果当前线程中已经存在事务, 方法调用会加入此事务, 果当前没有事务,就新建一个事务, 所以 ServiceB#methodB()
的事务只要遵循最普通的规则配置为 PROPAGATION_REQUIRED 即可, 如果 ServiceB#methodB
(我们称之为内部事务, 为下文打下基础) 抛了异常, 那么 ServiceA#methodA(我们称之为外部事务)
如果没有特殊配置此异常时事务提交 (即 +MyCheckedException的用法), 那么整个事务是一定要 rollback 的, 什么
Service 只能调 Dao 之类的言论纯属无稽之谈, spring 只负责配置了事务属性方法的拦截, 它怎么知道你这个方法是在
Service 还是 Dao 里 ?
说了这么半天, 那到底什么是真正的事务嵌套呢, 解释之前我们来看一下 Juergen Hoeller 的原话
PROPAGATION_REQUIRES_NEW starts a new, independent "inner" transaction for the given scope. This transaction will be committed or rolled back completely independent from the outer transaction, having its own isolation scope, its own set of locks, etc. The outer transaction will get suspended at the beginning of the inner one, and resumed once the inner one has completed.
Such independent inner transactions are for example used for id generation through manual sequences, where the access to the sequence table should happen in its own transactions, to keep the lock there as short as possible. The goal there is to avoid tying the sequence locks to the (potentially much longer running) outer transaction, with the sequence lock not getting released before completion of the outer transaction.
PROPAGATION_NESTED on the other hand starts a "nested" transaction, which is a true subtransaction of the existing one. What will happen is that a savepoint will be taken at the start of the nested transaction. íf the nested transaction fails, we will roll back to that savepoint. The nested transaction is part of of the outer transaction, so it will only be committed at the end of of the outer transaction.
Nested transactions essentially allow to try some execution subpaths as subtransactions: rolling back to the state at the beginning of the failed subpath, continuing with another subpath or with the main execution path there - all within one isolated transaction, and not losing any previous work done within the outer transaction.
For example, consider parsing a very large input file consisting of account transfer blocks: The entire file should essentially be parsed within one transaction, with one single commit at the end. But if a block fails, its transfers need to be rolled back, writing a failure marker somewhere. You could either start over the entire transaction every time a block fails, remembering which blocks to skip - or you mark each block as a nested transaction, only rolling back that specific set of operations, keeping the previous work of the outer transaction. The latter is of course much more efficient, in particular when a block at the end of the file fails.
Rolling back the entire transaction is the choice of the demarcation code/config that started the outer transaction.
So if an inner transaction throws an exception and is supposed to be rolled back (according to the rollback rules), the transaction will get rolled back to the savepoint taken at the start of the inner transaction. The immediate calling code can then decide to catch the exception and proceed down some other path within the outer transaction.
If the code that called the inner transaction lets the exception propagate up the call chain, the exception will eventually reach the demarcation code of the outer transaction. At that point, the rollback rules of the outer transaction decide whether to trigger a rollback. That would be a rollback of the entire outer transaction then.
So essentially, it depends on your exception handling. If you catch the exception thrown by the inner transaction, you can proceed down some other path within the outer transaction. If you let the exception propagate up the call chain, it's eventually gonna cause a rollback of the entire outer transaction.
也就是说, 最容易弄混淆的其实是 PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED, 那么这两种方式又有何区别呢? 我简单的翻译一下 Juergen Hoeller 的话 :
PROPAGATION_REQUIRES_NEW
启动一个新的, 不依赖于环境的 "内部" 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务,
它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行.
另
一方面, PROPAGATION_NESTED 开始一个 "嵌套的" 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时,
它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分,
只有外部事务结束后它才会被提交.
由此可见,
PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于,
PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务,
如果外部事务 commit, 潜套事务也会被 commit, 这个规则同样适用于 roll back.
那么外部事务如何利用嵌套事务的 savepoint 特性呢, 我们用代码来说话
- ServiceA {
- /**
- * 事务属性配置为 PROPAGATION_REQUIRED
- */
- void methodA() {
- ServiceB.methodB();
- }
- }
- ServiceB {
- /**
- * 事务属性配置为 PROPAGATION_REQUIRES_NEW
- */
- void methodB() {
- }
- }
这
种情况下, 因为 ServiceB#methodB 的事务属性为 PROPAGATION_REQUIRES_NEW, 所以两者不会发生任何关系,
ServiceA#methodA 和 ServiceB#methodB 不会因为对方的执行情况而影响事务的结果, 因为它们根本就是两个事务, 在
ServiceB#methodB 执行时 ServiceA#methodA 的事务已经挂起了 (关于事务挂起的内容已经超出了本文的讨论范围,
有时间我会再写一些挂起的文章) .
那么 PROPAGATION_NESTED 又是怎么回事呢? 继续看代码
- ServiceA {
- /**
- * 事务属性配置为 PROPAGATION_REQUIRED
- */
- void methodA() {
- ServiceB.methodB();
- }
- }
- ServiceB {
- /**
- * 事务属性配置为 PROPAGATION_NESTED
- */
- void methodB() {
- }
- }
现
在的情况就变得比较复杂了, ServiceB#methodB 的事务属性被配置为 PROPAGATION_NESTED,
此时两者之间又将如何协作呢? 从 Juergen Hoeller 的原话中我们可以找到答案, ServiceB#methodB 如果
rollback, 那么内部事务(即 ServiceB#methodB) 将回滚到它执行前的 SavePoint(注意,
这是本文中第一次提到它, 潜套事务中最核心的概念), 而外部事务(即 ServiceA#methodA) 可以有以下两种处理方式:
1. 改写 ServiceA 如下
- ServiceA {
- /**
- * 事务属性配置为 PROPAGATION_REQUIRED
- */
- void methodA() {
- try {
- ServiceB.methodB();
- } catch (SomeException) {
- // 执行其他业务, 如 ServiceC.methodC();
- }
- }
- }
这
种方式也是潜套事务最有价值的地方, 它起到了分支执行的效果, 如果 ServiceB.methodB 失败, 那么执行
ServiceC.methodC(), 而 ServiceB.methodB 已经回滚到它执行之前的 SavePoint,
所以不会产生脏数据(相当于此方法从未执行过), 这种特性可以用在某些特殊的业务中, 而 PROPAGATION_REQUIRED 和
PROPAGATION_REQUIRES_NEW 都没有办法做到这一点. (题外话 : 看到这种代码, 似乎似曾相识, 想起了
prototype.js 中的 Try 函数 )
2. 代码不做任何修改, 那么如果内部事务(即 ServiceB#methodB) rollback, 那么首先 ServiceB.methodB 回滚到它执行之前的 SavePoint(在任何情况下都会如此),
外部事务(即 ServiceA#methodA) 将根据具体的配置决定自己是 commit 还是 rollback (+MyCheckedException).
上面大致讲述了潜套事务的使用场景, 下面我们来看如何在 spring 中使用 PROPAGATION_NESTED, 首先来看 AbstractPlatformTransactionManager
- /**
- * Create a TransactionStatus for an existing transaction.
- */
- private TransactionStatus handleExistingTransaction(
- TransactionDefinition definition, Object transaction, boolean debugEnabled)
- throws TransactionException {
- ... 省略
- if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
- if (!isNestedTransactionAllowed()) {
- throw new NestedTransactionNotSupportedException(
- "Transaction manager does not allow nested transactions by default - " +
- "specify 'nestedTransactionAllowed' property with value 'true'" );
- }
- if (debugEnabled) {
- logger.debug( "Creating nested transaction with name [" + definition.getName() + "]" );
- }
- if (useSavepointForNestedTransaction()) {
- // Create savepoint within existing Spring-managed transaction,
- // through the SavepointManager API implemented by TransactionStatus.
- // Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization.
- DefaultTransactionStatus status =
- newTransactionStatus(definition, transaction, false , false , debugEnabled, null );
- status.createAndHoldSavepoint();
- return status;
- }
- else {
- // Nested transaction through nested begin and commit/rollback calls.
- // Usually only for JTA: Spring synchronization might get activated here
- // in case of a pre-existing JTA transaction.
- doBegin(transaction, definition);
- boolean newSynchronization = ( this .transactionSynchronization != SYNCHRONIZATION_NEVER);
- return newTransactionStatus(definition, transaction, true , newSynchronization, debugEnabled, null );
- }
- }
- }
一目了然
1. 我们要设置 transactionManager 的 nestedTransactionAllowed 属性为 true, 注意, 此属性默认为 false!!!
再看 AbstractTransactionStatus#createAndHoldSavepoint() 方法
- /**
- * Create a savepoint and hold it for the transaction.
- * @throws org.springframework.transaction.NestedTransactionNotSupportedException
- * if the underlying transaction does not support savepoints
- */
- public void createAndHoldSavepoint() throws TransactionException {
- setSavepoint(getSavepointManager().createSavepoint());
- }
可以看到 Savepoint 是 SavepointManager.createSavepoint 实现的, 再看 SavepointManager 的层次结构, 发现
其 Template 实现是 JdbcTransactionObjectSupport, 常用的 DatasourceTransactionManager, HibernateTransactionManager
中的 TransactonObject 都是它的子类 :
JdbcTransactionObjectSupport 告诉我们必须要满足两个条件才能 createSavepoint :
2. java.sql.Savepoint 必须存在, 即 jdk 版本要 1.4+
3. Connection.getMetaData().supportsSavepoints() 必须为 true, 即 jdbc drive 必须支持 JDBC 3.0
确保以上条件都满足后, 你就可以尝试使用 PROPAGATION_NESTED 了. (全文完)
![]() |
155107993719940.jpg (34 K) |
发表评论
-
spring2.0-2.5-3.0变化[转]
2011-09-10 00:50 11662.5的新特性 Spri ... -
Spring的JMX支持
2011-08-10 20:31 1194Spring的JMX支持所提供的特性使你容易而又透明地将你的S ... -
Spring.Net入门篇(一) [转]
2011-07-20 01:15 2392简介 从OO到AOP,一路走来就是眼花缭 ... -
开源框架spring详解-----AOP的深刻理解
2011-07-01 18:31 1060AOP是一种不同于OOP(面向对象编程)的编程模式,它 ... -
AOP学习——配置Spring AOP【2】,使用annotation
2011-07-01 13:41 1018使用 annotation 配置 AOP ... -
AOP学习——配置Spring AOP【1】,使用xml文件
2011-07-01 13:34 934使用 Spring AOP ,除了 spring ... -
Spring2.5注释语法(上)——Spring2.5注释驱动的IoC
2011-07-01 10:30 699Spring2.5 注释语法( 上) ... -
Spring2.5注释驱动与基于注释的MVC
2011-07-01 10:28 776写在前面: 好长� ... -
BoneCP,Proxool,DBCP,C3P0 参数介绍的简介与内容
2011-06-15 12:31 1210DBCP,C3P0,Proxool,BoneCP详细参数介绍 ... -
使用Spring HTTP invoker进行远程调用
2011-06-08 19:03 1084http://www.kompakar.com.cn/disc ... -
spring http invoker 高级篇
2011-06-08 19:03 1254默认情况下,客户端的HttpInvokerProxy使用J2S ... -
Spring管理Filter和Servlet
2011-06-08 19:02 998Spring 管理 filter 和 ser ... -
Spring HTTP invoker简介
2011-06-08 19:01 1000Spring HTTP invoker 简介 S ... -
详解Spring Web MVC中的DispatcherServlet类
2011-06-08 00:55 1295Spring 的Web MVC框架是围绕Dispatch ... -
spring2.5注解式MVC配置
2011-06-08 00:49 1378转载自http://www.ibm.com/developer ... -
Spring + iBatis 的多库横向切分简易解决思路
2011-05-13 00:26 11321.引言 笔者最 ... -
Spring多数据源解决方案
2011-05-13 00:14 979在很多大型应用中都会对数据进行切分,并且采用多个数据库实例进行 ... -
Spring 初始化之旅(转)
2011-03-23 09:29 956Spring源码学习 � ... -
Spring工具类,提供取得Bean的方法,方便单元测试
2011-03-15 15:46 1360Spring工具类,提供取得Bean的方法,方便单元测试 ... -
Spring 的优秀工具类盘点
2011-03-15 15:38 513Spring 的优秀工具类盘点,第 1 部分: 文件资源操作和 ...
相关推荐
- **Spring事务传播机制解惑**:深入理解Spring框架下的事务管理机制,确保事务的正确配置和应用。 ### 表义命名规范 - **规则**:定义了领域对象、服务层、Web层等命名规则,以及常用的中英文术语对照,确保命名...
内容概要:本文档详细介绍了基于 MATLAB 实现的 LSTM-AdaBoost 时间序列预测模型,涵盖项目背景、目标、挑战、特点、应用领域以及模型架构和代码示例。随着大数据和AI的发展,时间序列预测变得至关重要。传统方法如 ARIMA 在复杂非线性序列中表现欠佳,因此引入了 LSTM 来捕捉长期依赖性。但 LSTM 存在易陷局部最优、对噪声鲁棒性差的问题,故加入 AdaBoost 提高模型准确性和鲁棒性。两者结合能更好应对非线性和长期依赖的数据,提供更稳定的预测。项目还展示了如何在 MATLAB 中具体实现模型的各个环节。 适用人群:对时间序列预测感兴趣的开发者、研究人员及学生,特别是有一定 MATLAB 编程经验和熟悉深度学习或机器学习基础知识的人群。 使用场景及目标:①适用于金融市场价格预测、气象预报、工业生产故障检测等多种需要时间序列分析的场合;②帮助使用者理解并掌握将LSTM与AdaBoost结合的实现细节及其在提高预测精度和抗噪方面的优势。 其他说明:尽管该模型有诸多优点,但仍存在训练时间长、计算成本高等挑战。文中提及通过优化数据预处理、调整超参数等方式改进性能。同时给出了完整的MATLAB代码实现,便于学习与复现。
palkert_3ck_01_0918
pepeljugoski_01_1106
tatah_01_1107
AB PLC例程代码项目案例 【备注】 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用!有问题请及时沟通交流。 2、适用人群:计算机相关专业(如计科、信息安全、数据科学与大数据技术、人工智能、通信、物联网、自动化、电子信息等)在校学生、专业老师或者企业员工下载使用。 3、用途:项目具有较高的学习借鉴价值,不仅适用于小白学习入门进阶。也可作为毕设项目、课程设计、大作业、初期项目立项演示等。 4、如果基础还行,或热爱钻研,亦可在此项目代码基础上进行修改添加,实现其他不同功能。 欢迎下载!欢迎交流学习!不清楚的可以私信问我!
题目:基于单片机的步进电机控制系统 模块: 主控:AT89C52RC 步进电机(ULN2003驱动) 按键(3个) 蓝牙(虚拟终端模拟) 功能: 1、可以通过蓝牙远程控制步进电机转动 2、可以通过按键实现手动与自动控制模式切换。 3、自动模式下,步进电机正转一圈,反转一圈,循环 4、手动模式下可以通过按键控制步进电机转动(顺时针和逆时针)
AB PLC例程代码项目案例 【备注】 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用!有问题请及时沟通交流。 2、适用人群:计算机相关专业(如计科、信息安全、数据科学与大数据技术、人工智能、通信、物联网、自动化、电子信息等)在校学生、专业老师或者企业员工下载使用。 3、用途:项目具有较高的学习借鉴价值,不仅适用于小白学习入门进阶。也可作为毕设项目、课程设计、大作业、初期项目立项演示等。 4、如果基础还行,或热爱钻研,亦可在此项目代码基础上进行修改添加,实现其他不同功能。 欢迎下载!欢迎交流学习!不清楚的可以私信问我!
AB PLC例程代码项目案例 【备注】 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用!有问题请及时沟通交流。 2、适用人群:计算机相关专业(如计科、信息安全、数据科学与大数据技术、人工智能、通信、物联网、自动化、电子信息等)在校学生、专业老师或者企业员工下载使用。 3、用途:项目具有较高的学习借鉴价值,不仅适用于小白学习入门进阶。也可作为毕设项目、课程设计、大作业、初期项目立项演示等。 4、如果基础还行,或热爱钻研,亦可在此项目代码基础上进行修改添加,实现其他不同功能。 欢迎下载!欢迎交流学习!不清楚的可以私信问我!
内容概要:本文详细介绍了建设智慧校园平台所需的六个关键步骤。首先通过需求分析深入了解并确定校方和使用者的具体需求;其次是规划设计阶段,依据所得需求制定全面的建设方案。再者是对现有系统的整合——系统集成,确保新旧平台之间的互操作性和数据一致性。培训支持帮助全校教职工和学生快速熟悉新平台,提高效率。实施试点确保系统逐步稳定部署。最后,强调持续改进的重要性,以适应技术和环境变化。通过这一系列有序的工作,可以使智慧校园建设更为科学高效,减少失败风险。 适用人群:教育领域的决策者和技术人员,包括负责信息化建设和运维的团队成员。 使用场景及目标:用于指导高校和其他各级各类学校规划和发展自身的数字校园生态链;目的是建立更加便捷高效的现代化管理模式和服务机制。 其他说明:智慧校园不仅仅是简单的IT设施升级或软件安装,它涉及到全校范围内的流程再造和创新改革。
该文档系统梳理了人工智能技术在商业场景中的落地路径,聚焦内容生产、电商运营、智能客服、数据分析等12个高潜力领域,提炼出100个可操作性变现模型。内容涵盖AI工具开发、API服务收费、垂直场景解决方案、数据增值服务等多元商业模式,每个思路均配备应用场景拆解、技术实现路径及收益测算框架。重点呈现低代码工具应用、现有平台流量复用、细分领域自动化改造三类轻量化启动方案,为创业者提供从技术选型到盈利闭环的全流程参考。
palkert_3ck_02_0719
克鲁格曼专业化指数,最初是由Krugman于1991年提出,用于反映地区间产业结构的差异,也被用来衡量两个地区间的专业化水平,因而又称地区间专业化指数。该指数的计算公式及其含义可以因应用背景和具体需求的不同而有所调整,但核心都是衡量地区间的产业结构差异或专业化程度。 指标 年份、城市、第一产业人数(first_industry1)、第二产业人数(second_industry1)、第三产业人数(third_industry1)、专业化指数(ksi)。
AB PLC例程代码项目案例 【备注】 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用!有问题请及时沟通交流。 2、适用人群:计算机相关专业(如计科、信息安全、数据科学与大数据技术、人工智能、通信、物联网、自动化、电子信息等)在校学生、专业老师或者企业员工下载使用。 3、用途:项目具有较高的学习借鉴价值,不仅适用于小白学习入门进阶。也可作为毕设项目、课程设计、大作业、初期项目立项演示等。 4、如果基础还行,或热爱钻研,亦可在此项目代码基础上进行修改添加,实现其他不同功能。 欢迎下载!欢迎交流学习!不清楚的可以私信问我!
精品推荐,通信技术LTE干货资料合集,19份。 LTE PCI网络规划工具.xlsx LTE-S1切换占比专题优化分析报告.docx LTE_TDD问题定位指导书-吞吐量篇.docx LTE三大常见指标优化指导书.xlsx LTE互操作邻区配置核查原则.docx LTE信令流程详解指导书.docx LTE切换问题定位指导一(定位思路和问题现象).docx LTE劣化小区优化指导手册.docx LTE容量优化高负荷小区优化指导书.docx LTE小区搜索过程学习.docx LTE小区级与邻区级切换参数说明.docx LTE差小区处理思路和步骤.docx LTE干扰日常分析介绍.docx LTE异频同频切换.docx LTE弱覆盖问题分析与优化.docx LTE网优电话面试问题-应答技巧.docx LTE网络切换优化.docx LTE高负荷小区容量优化指导书.docx LTE高铁优化之多频组网优化提升“用户感知,网络价值”.docx
matlab程序代码项目案例 【备注】 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用!有问题请及时沟通交流。 2、适用人群:计算机相关专业(如计科、信息安全、数据科学与大数据技术、人工智能、通信、物联网、自动化、电子信息等)在校学生、专业老师或者企业员工下载使用。 3、用途:项目具有较高的学习借鉴价值,不仅适用于小白学习入门进阶。也可作为毕设项目、课程设计、大作业、初期项目立项演示等。 4、如果基础还行,或热爱钻研,亦可在此项目代码基础上进行修改添加,实现其他不同功能。 欢迎下载!欢迎交流学习!不清楚的可以私信问我!
pepeljugoski_01_0508
szczepanek_01_0308
oif2007.384.01_IEEE
stone_3ck_01_0119