個人心得

這段時間一直在修改ECperf，主要心得都是EJB應用方面的，對EJB部署的復雜和調試的痛苦深有感觸，其中主要原因可能是我對EJB不太熟悉，沒有用EJB開發應用的經驗，以下的幾點心得在熟手看來可能是理所當然的，但卻折磨我了好久。

1．              EJB部署

部署應用實際上就是將應用安裝到應用服務器上，按書上部署Hell Word時沒有遇到絲毫困難，但在部署ECperf時卻冒出了一堆問題。其中困擾我最久的就是EJB互相引用的問題，實際上只需要將所有的引用關系和JNDI名寫入sun-ejb-jar.xml就可以了（借助sun的部署工具很容易實現，不同的應用服務器會有不同的文件名如，格式可能也會不同）。在ejb-jar.xml中，每個EJB必須申明自己引用的EJB的類型，home接口，remote接口，和ejb的引用名，引用名不需要與JNDI名相同，在sun-ejb-jar.xml要申明ejb引用名對應的JNDI名。DataSource也需要如此設置，對于env-entry好像不需要在sun-ejb-jar.xml中申明。由此可以看出應用服務器對EJB所能訪問的資源做了嚴格的控制，而ejb不是直接引用JNDI名，也為ejb應用提供了一定的靈活性。

2．              EJB調用

在同一容器調用EJB和遠程調用EJB有很大不同。同一容器中調用者與被調用者有相同的Context，因此不需要額外設置，而在遠程調用需要指定java.naming.factory.initial和java.naming.provider.url，另外還要部署時產生的client jar。

在調用PortableRemoteObject.narrow()得到home接口時拋出java.lang.ClassCastException

一般將client jar 放到 classpath中就可以解決，這里主要用到的是remote接口和home接口的stub。如果不將client jar 放到classpath中也可以得到home的接口，但由于使用了不同的classload，在用PortableRemoteObject.narrow()進行轉型被視為不同的類而轉型失敗，我在用sun的部署工具得到的 client jar中竟然沒有stub（可能是部署文件的問題），所以遠程調用始終不成功。

3．              下一步學習的方向

繼續研究遠程對象是如何返回的

Classload 是如何工作的

JDBC中關于分布式事務的處理方式

容器處理事務的規則