JCA 1.5: 优化和生命周期管理[Java编程]
本文“JCA 1.5: 优化和生命周期管理[Java编程]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：
JCA 标准的新版本不会使利用程序与后端系统之间的衔接变得更快,但 JCA 1.5 引入了两组接口,可以加快利用衔接的利用程序的运行.第一组接口解除了从前 JCA 版本中利用服务器 style="COLOR: #000000" href="http://server.it168.com/" target=_blank>服务器管理衔接句柄方法的限制.
很多读者都知道,J2EE 支持两种衔接利用情势,本文称之为 get-use-close 和 cached-handle.对这些情势的进一步解析有助于理解 JCA 1.5 在这方面所带来的性能改进.
get-use-close
在 get-use-close 情势中,利用程序在需求新衔接时,老是先获得新衔接,然后利用,然后再关闭它,如清单 1 所示.(为清楚起见,本文没有在示例清单中加入非常处理逻辑.)
清单 1. 利用 get-use-close 情势的一个 Enterprise JavaBean (EJB)
| 1 public class GetUseCloseEJB implements SessionBean { 2 ... 3 public void businessMethod() { 4 InitialContext context = new InitialContext(); 5 DataSource dataSource = (DataSource)context.lookup("java:comp/env/jdbc/mydatasource"); 6 Connection connection = datasource.getConnection(); 7 ... 8 connection.close(); 9 } 10 } |
get-use-close 情势看起来效率不高,但是利用服务器实现的衔接池可降低"得到"操作的本钱.此外,因为利用程序只在需求时才保存衔接,所以利用程序的差别实例大概部份可以反复利用该衔接,从而降低了总的资源占用,如图 1 所示.
图 1. 利用中的 get-use-close 情势
如图 1 所示,每当 bean 办法调用 getConnection 时,衔接纳理器城市反复利用池中托管的衔接,并只成立一个新衔接句柄.当衔接句柄告诉衔接纳理器它已关闭时,托管的衔接就被排除并返回池中.图 1 中的绿色线条表示托管衔接与利用程序的这个实例相关联的时间.
cached-handle
在 cached-handle 情势中,利用程序在一开始是得到衔接,然后在一个实例字段中缓存对它的引用,如清单 2 所示.
清单 2. cached-handle 情势
| 1 public class CachedHandleEJB implements SessionBean { 2 private Connection _connection; 3 ... 4 public void ejbCreate() { 5 InitialContext context = new InitialContext(); 6 DataSource dataSource = (DataSource)context.lookup("java:comp/env/jdbc/mydatasource"); 7 _connection = datasource.getConnection(); 8 } 9 public void businessMethod() { 10 ... 11 } 12 } |
利用程序开辟人员普通都利用 cached-handle 办法,因为他们认为这样利用程序的性能会更好.但是因为 get-use-close 情势中衔接池的作用,这两种利用情势的性能差别普通来说是很小的.固然 cached-handle 情势可以使业务办法中的逻辑更简单,但是需求额外的逻辑以便在钝化(passivation)时关闭衔接,并在激活时重建衔接.当容器破坏 bean 时(如由于办法生成了一个运行时非常),还有大概留下翻开的衔接.
cached-handle 情势的最大问题是当 bean 大概 servlet 的一个实例利用该衔接时,其他实例就不能利用它——因此衔接数最多只会有实例那么多.如图 2 所示.
图 2. 利用中的 cached-handle 情势
从图 2 中可以看到,成立 EJB 时(从绿色线条开始),托管的衔接与衔接句柄关联,并且这个 bean 实例以外的任何其他对象都不能利用这个衔接.(绿色线条无限延伸.)
针对这种情形,JCA 1.5 标准引入了两个新的接口,如清单 3 所示.
清单 3. 解除关联(dissociation)和惰性关联(lazy association)接口
| 1 public interface DissociatableManagedConnection { 2 void dissociateConnections() throws ResourceException; 3 } 4 public interface LazyAssociatableConnectionManager { 5 void associateConnection(Object connection, 6 ManagedConnectionFactory mcf, 7 ConnectionRequestInfo cxReqInfo) 8 throws ResourceException 9 } |
解除关联
资源适配器的托管衔接实现第一个接口—— 解除关联 接口——以向衔接纳理器表明适配器支持这种优化.当衔接暂时超越范围时(即当 bean 大概 servlet 办法退出时),假如衔接纳理器支持这种优化的话,它便可以解除由利用程序利用的衔接句柄与表示物理资源的托管衔接的关联.这使托管衔接可以返回衔接池,为利用程序的其他部份所利用.
惰性关联
这种优化利用 惰性关联,而不是在下次调用办法时重新将衔接句柄与托管衔接关联.假如办法没有利用衔接,大概它只调用衔接句柄上不需求拜候后端的简单办法,那么托管衔接未必会从池中移出.相反,当衔接句柄肯定它不需求与一个托管衔接重新关联时,它便可以将衔接纳理器强迫转换为 LazyAssociatableConnectionManager 并调用 associateConnection 办法.该办法以衔接句柄为第一个参数,然后是托管衔接厂,以及对 allocateConnection 的第一次调用时传送的恳求信息.然后衔接纳理器从池中找到另一个符合的托管衔接,并利用这个托管衔接的 associateConnection 办法将它与衔接句柄关联.
图 3 显示了这种优化对 图 2 中的 cached-handle 用法的效果.
图 3. 惰性关联降低资源用量
图 3 中虚线箭头表示办法完成时 EJB 容器对衔接纳理器的告诉.这时,托管的衔接与衔接句柄解除关联,只有当办法试牟利用这个句柄时,托管衔接才会重新关联.短的绿色线条显示托管衔接目前绑定到 EJB 上,以缩短时间并可以在别的地方重新利用.
在图 4 中可以看到,得到衔接后,XAResource 当即征募到了事件中(即接纳一个开始流程).这意味着当事件办法完毕时,流程需求在资源处完毕,即便办法没有在事件中利用衔接.
假如在事件中触及另一项资源,就会强迫举行不必要的两阶段提交,招致额外的预备流程.这里的惟一可取之处是资源管理器仍旧可以从预备调用中返回 XA_RDONLY (用于"read only")以表明它实际没有做任何工作.事件管理器不需求在那个资源管理器处完成调用,并且假如在事件中只有一个资源管理器真正做了工作,那么事件管理器也答应以避免日记文件中的惰性写操作.
惰性征募
目前您该当熟习到除非绝对需求,不然不要在事件中征募.JCA 1.5 标准供应了一个办理筹划:惰性征募.清单 4 显示了支持这各种优化所引入的两个接口.
清单 4. 惰性征募的接口
| 1 public interface LazyEnlistableManagedConnection { 2 } 3 public interface LazyEnlistableConnectionManager { 4 void lazyEnlist(ManagedConnection mc) 5 throws ResourceException; 6 } |
LazyEnlistableManagedConnection 接口是由托管衔接实现的标志接口,用以向衔接纳理器表明在事件中成立新的衔接大概在衔接已经存在的情形下开始一个新的事件时,它不需求将托管衔接急迫征募到现有事件中.假如衔接句柄预备履行该当是任一事件中的一部份的某些工作,并且它的托管衔接还没有征募,那么该当肯定衔接纳理器能否实施了 LazyEnlistableConnectionManager 接口.假照实施了,那么它该当调用传送托管衔接的 lazyEnlist 办法.这个办法不返回任何后果,但是假如调用线程关联了一个事件,那么这时就征募托管衔接的 XAResource.假如衔接没有被征募,那么它需求在背面每一项工作之前再次调用 lazyEnlist,以查抄在上次调用这个办法之后,是不是没有启动过事件.
图 5 显示了这个新的事件序列.
图 5. 惰性事件征募
在图 5 中可以看到,在得到衔接时,XAResource 不再急迫征募.相反,衔接纳理器会等候,直到衔接用 lazyEnlist 调用表明它要完成一些事件工作时,才会征募 XAResource.
什么时刻呈现错误
JCA 标准的第一个版本供应了一种让资源适配器在衔接呈现严重错误时告诉衔接纳理器的机制.这是 ConnectionEventListener 接口的 connectionErrorOccurred 办法.收到这个告诉后,衔接纳理器就会毁环发送事件的托管衔接,这样就不会再利用它.这些都是不错的.但是,假如到后端的衔接丧失了,那么池中的很多托管衔接也很有大概不能再利用.
针对这个问题,JCA 1.5 以 ValidatingManagedConnectionFactory 接口的方法引入了一种雅洁的办理筹划,如清单 5 所示.
清单 5. 用于肯定无效衔接的接口
| 1 public interface ValidatingManagedConnectionFactory { 2 Set getInvalidConnections(Set connectionSet) 3 throws ResourceException; 4 } 5 |
由托管衔接厂实现的 ValidatingManagedConnectionFactory 接口包含一个办法——getInvalidConnections——它以一组托管衔接为参数,返回资源适配器认为无效的一个子集.资源适配器的考证可以采纳任何情势,不过普通触及到对后端的某种"ping"操作,以测试衔接.然后衔接纳理器在资源适配器指导衔接错误时调用这个办法,乃至按期调用该办法,以便从池中解除坏掉的衔接.
开始和完毕
最初的 JCA 版本为托管衔接及其相关联的衔接句柄供应了具体的生命周期情势,但是它没有为资源适配器供应这种概念.只有当成立了托管衔接厂后,布置的资源适配器才知道它的存在.JCA 1.5 中引入的 ResourceAdapter 接口对此举行了改正,如清单 6 所示.
清单 6. 新资源适配器接口的生命周期办法
| 1 public interface ResourceAdapter { 2 void start(BootstrapContext ctx) 3 throws ResourceAdapterInternalException; 4 void stop(); 5 ... 6 } |
资源适配器可以在其布置描写符(ra.xml)的 resourceadapter-class 元素中给出实现这个接口的类的名称.除了实现 ResourceAdapter 接口,这个类可以通过 JavaBean 款式支持某些属性.与托管衔接厂一样,在布置描写符中可以声明这些属性及其默许值,如清单 7 所示.在安装了资源适配器后,利用服务器将答应管理员覆盖这些默许值.
清单 7. 资源适配器布置描写符
| 1 <connector> 2 ... 3 <resourceadapter> 4 <resourceadapter-class> 5 example.ExampleResourceAdapterImpl 6 </resourceadapter-class> 7 <config-property> 8 <config-property-name>ServerName</config-property-name> 9 <config-property-type>java.lang.String</config-property-type> 10 <config-property-value>MyServer</config-property-value> 11 </config-property> 12 <config-property> 13 <config-property-name>PortNumber</config-property-name> 14 <config-property-type>java.lang.String</config-property-type> 15 <config-property-value>1976</config-property-value> 16 </config-property> 17 </resourceadapter> 18 ... 19 </connector> |
在启动时,利用服务器会成立在布置描写符中指定的类的一个实例,并设置管理员供应的属性.这个类必须按照这些属性实现一个 equals 办法,这样利用服务器便可以保证它不会成立一个以上一样的实例.然后会调用 start 办法,向它传送一个实现了 BootstrapContext 接口的对象.可以用这个对象成立计时器、调度其他线程上的工作和掌握导入的事件,在本系列的第 2 部份中将更具体地谈论全部这些内容.这个办法将不会堵塞并会及时返回.
利用服务器普通会在关闭大概解除布置资源适配器之前,对资源适配器调用 stop 办法.JCA 1.5 标准描写了这个历程的两个阶段.首先,利用服务器保证依靠资源适配器的全部利用程序都已终止.这可保证程序线程不再利用资源适配器对象,并且全部事件都已完成.然后利用服务器调用 stop 办法.这时,资源适配器将履行一个有序的关闭(比方,释放网络和利用服务器资源,并将全部缓存的数据强行送回后端).调用 stop 后,利用服务器将不会重新利用资源适配器实例.
为了保存向后兼容性,ManagedConnectionFactory 没有改变,但是假如但愿外部资源可以操纵资源适配器具有的功效,那么还要实现清单 8 所示的新的 ResourceAdapterAssociation 接口.
清单 8. ResourceAdapterAssociation 接口
| 1 public interface ResourceAdapterAssociation { 2 ResourceAdapter getResourceAdapter(); 3 void setResourceAdapter(ResourceAdapter ra) 4 throws ResourceException; 5 } |
构建了托管衔接厂之后,利用服务器将调用 setResourceAdapter 办法以便将它与其资源适配器关联在一同.在托管衔接厂的生命周期内这种关联将会固定下来.这种办法只调用一次.
完毕语
本文展示了 JCA 1.5 为现有出站契约带来的四项加强功效.惰性关联和征募优化会提高利用衔接的利用程序的性能,考证托管衔接厂会改进对弊端情形的处理.在资源适配器级别引入生命周期管理为资源适配器供应了多种风趣的新机会.本系列的第 2 部份将解析如安在这个底子上成立新的工作管理和事件流入契约.
以上是“JCA 1.5: 优化和生命周期管理[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：
| 本文地址： | 与您的QQ/BBS好友分享! |
- 好的评价 如果您觉得此文章好，就请您
0%(0) 
- 差的评价 如果您觉得此文章差，就请您
0%(0) 
中查找“JCA 1.5: 优化和生命周期管理”更多相关内容
中查找“JCA 1.5: 优化和生命周期管理”更多相关内容