EJB3.1新特性(部分)

这个系列的文章是EJB3.1专家小组正在研发的下个版本JavaEE规范的预览。EJB3.0去掉了沉重的编程到精通，一个简单的Java对象正是你很需要的，尤其是在你不需要做过多的单元测试和松耦合并不是应用的更核心要求的之后。 EJB3.1允许你这样做。现在，Session Beans不需要任何的接口，就象JPA Entity 和Message Driven Beans。

所有你必须做的就是给一个POJO标记上@Stateless或者@Stateful来受到所有的EJB功能。下面是一个根据《EJB 3 in Action》中Session Bean章节的一个列子修改的： @Stateless public class PlaceBidBean { @PersistenceContextPrivate EntityManager entityManager;public void placeBid (Bid bid) {entityManager.persist(bid);} } 下面为这个bean添加了一些新的特点： @Stateless @WebService public class PlaceBidBean {@PersistenceContextprivate EntityManager entityManager; @WebMethod public void placeBid (Bid bid) {entityManager.persist(bid);} } 在里面的事例中，我们使用JAX-WS 2.0吧placeBid方法发布为一个web service。

同时我们使用JPA来持久化一个Bid entity。PlaceBidBean拥有了所有无状态Session Bean的功能，包括在后端的对象池、线程安全、组件生命周期、、安全跟声明事务。比如，如果你对EJB3.0熟悉的话，你会想placeBid方法是默认的被一个容器管理的JTA包装出来的。该bean同时也能成为RMI基础的远程端。 除了可跟简单的bean类型一起工作，去掉接口也使EJB3.1 beans在WebBeans中简洁实用。WebBeans（JSR 299）ejb3.1从入门到精通，在JBoss Seam中受到长期灵感。WebBeans无缝的集成了JSF,JPA和EJB3.1，从而使Java EE 6整整的成为了一个整体。 Singleton Beans EJB3.1 Singleton Beans 是何GOF Singleton 模式相同的模块。在Java EE 上下文中，他们被拿来储存应用级别的共享数据。想象你必须缓存一些数据在存储中而不是重复的从中反复的查询。Stateless Session Beans和Stateful Session Beans 都不能达到这些需求。

虽然Stateful Session Beans可以拥有session级别的缓存，但它的数据不能再整个应用级别其他的模块轻松访问。 有很多种方法可以满足这些需求，一种简单的方法就是使用static 属性以及GOF Singleton模式的POJOs。一种稍微复杂的缓解思路是使用Servlet容器的Applcation级别空间，JBoss Cache，OSCache，JCS和SwarmCache等。商业的解决方案包括Tangosol Coherence和Terracotta。虽然这种方式在大部分情况下很有用，但是它们也存在诸多的不足。一些不是线程安全的(static fields,Singleton POJOs),一些不支持事务的(Singleton POJOS,Servlet application scope,OSCache,JCS,SwarmCache），这些都不支持远程甚至没有任何安全措施。除了某些通用的解决方案之外，现在可以使用Enter EJB3.1 Singletons来缓解。 容器用来维持对一个EJB3.1 Singleton实例的唯一性。这意味着Singletons可以保存应用层中的状况。

因为是一个EJB，所以，Singleton拥有所有的中间服务——声明事务管理，安全，远程，线程管理，依赖注入，组件生命周期回调，等等。和其他的EJBs一样，Singleton也是标注性POJO。下面是一个例子： @Singleton public class DiscountRateBean { @PersistenceContext private EntityManager entityManager; private Rate rate; @PostConstruct private void init() { rate = entityManager.find(Rate.class, 1); } @PreDestroy private void destroy() { entityManager.merge(rate); } public void setRate(Rate rate) { this.rate = rate; } public Rate getRate() { return rate; } } 在这个列子中使用了JPA和bean生命周期回调在推进阶段加载数据，并在bean销毁的之后保存其值。

所有的调用getRate和setRate的方式都是直接连接到DiscountRateBean的唯一例子的共享数据。你将要看到一个有趣的难题——如果容器没有调用pre-destroy回调方法的机会，任何一个修改都可能丢失。我们将在以下的文章中介绍如何借助一个类似于Corn的定时器（cron-like timers）来增加这些问题。 默认的，所有的Singleton方法都是现成安全的甚至支持事务。这意味着多线程的调用这个bean是有序列的，并且所有的方式都假定具有一个REQUIRED的事务属性。你可以借助使用@TransactionManagement和@TransactionAttribute标签来改变事务的类型——就像你在Stateful或者Stateless Session Bean中那种。如果你在现实中接触过应用的话，你会了解吧getRate和setRate方法都列队的访问，是巨大 的一个性能瓶颈。现实中，我们会在getRate方法上使用一个只读锁以及在setRate方法上使用一个读-写锁。你可以使用@ConcurrencyAttribute实现： @Singleton public class DiscountRateBean { @PersistenceContext private EntityManager entityManager; private Rate rate; @PostConstruct private void init() { rate = entityManager.find(Rate.class, 1); } @PreDestroy private void destroy() { entityManager.merge(rate); } @ConcurrencyAttribute(READ_WRITE_LOCK) public void setRate(Rate rate) { this.rate = rate; } @ConcurrencyAttribute(READ_LOCK) public Rate getRate() { return rate; } } 熟悉Doug Lea's工作的人都明白，READ_LOCK和READ_WRITE_LOCK术语来自于java.util.concurrent。

一些应用的共享数据确实是只读的，任何锁其实都不是必要的。在这些状况下，你只应该创建unsynchronized Singleton： @Singleton @ConcurrencyAttribute(NO_LOCK) // READ_LOCK would also work... public class DiscountRateBean { @PersistenceContext private EntityManager entityManager; private Rate rate; @PostConstruct private void init() { rate = entityManager.find(Rate.class, 1); } public Rate getRate() { return rate; } } @ConcurrencyAttribute(READ_LOCK),@ConcurrencyAttribute(READ_WRITE_LOCK)和@ConcurrencyAttribute(NO_LOCK)的一个改变是这几个标签将设置为@ConcurrencyReadLock，@ConcurrencyReadWriteLock和@ConcurrencyNoLock。

为了结合这些基础的标签格式，@TransactionAttribute会分成@TransactionRequired，@RequiresNewTranscation,@TransactionNotSupported等等。不过有些意见认为这种会降低代码的复杂度。 同样，你或许不期望容器来管理Singleton的并发，下面是一个bean manage concurrency的举例： @Singleton @ConcurrencyManagement(BEAN) public class DiscountRateBean { @PersistenceContext private EntityManager entityManager; private Rate rate; @PostConstruct private void init() { rate = entityManager.find(Rate.class, 1); } @PreDestroy private void destroy() { entityManager.merge(rate); } public synchronized void setRate(Rate rate) { this.rate = rate; } public synchronized Rate getRate() { return rate; } } 注意这个事例中我们同步的关键字（synchronized keyword)来管理并发。

因为容器不需要接口了，所以你可以使用任何你喜欢的同步管理体制，包括但并不仅仅限制为java.util.concurrent包。目前，新的concurrency管理特点仅仅限制于EJB3.1 Singleton.不过可能会扩展至其它的bean上。 Singletons 同样也可借助加载顺序提供延迟/迫切加载，和Singleton的依赖管理。这里我们暂时不争论很多话题。虽然完善没有提到集群的支持，但因该是集群安全的。 EJB3.1更多的特点 以上提及的两个特点也是冰山一角。还有众多有趣的特点列在JSR议案中，下面是其中一些： 1，在Servlet容器中支持EJBs，包括简单打包选项。目前的看法是允许EJBs放在WEB-INF/classes目录下面，吧ebj-jar.xml放在WEB-INF同级。就象web.xml。同样，你可以把EJB JAR 包放在WEB-INF/lib下 2，EJB Timer服务提升类似CRON的作业调度模式，开发时时间对象构建，Stateful Session Bean使用调度对象标记等。 3，通过Stateful Session Bean web service终点提供有状况的web service。

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-134406-1.html