关于Session序列化的问题

相信很多人看过[在Weblogic上配置Hibernate的SF到JNDI],[Struts结合Hibernate]的文章,这些文章中都提到将SessionFacotry作为唯一一个实例在系统启动前先初始化好,然后绑定到jndi上,应用程序lookup这个SF后在openSession来获得可用的Session.
现在我有一个问题,假想我有个Swing程序,远程lookup到这个SF,然后通过openSession来获得可用的Session 这种方式是否可行? 因为SessionFactory 实现了序列化( Serializable), Session也实现了序列化,但是不知道SessionFactory 和Session内所含的其它类是否都是实现了序列化,如果不是的话,通过lookup来获得SF,在获得Session,进行其它操作时就有可能发生错误了? 这解答!

其实这个问题你自己一试便知，都没有提问的必要。答案肯定是不行的。目前只有EJB才支持远程方法调用，Hibernate是不支持远程方法调用的。

针对你这个应用，比较好的做法是业务逻辑全部都在服务器端实现(速度快，效率高)，最后将数据VO序列化到客户端的Swing程序上来，而swing只负责显示数据。

至于Swing如何和服务器端的业务Bean通讯，来获得序列化的VO，你可以采用的办法很多：例如可以通过RMI来调用服务器端的EJB；可以通过HTTP协议，调用服务器端的Servlet；可以通过SOAP协议，调用服务器端的Web Services等等。

"答案肯定是不行的。"
这个我认为也是!
"目前只有EJB才支持远程方法调用，Hibernate是不支持远程方法调用的。 "
这个我持反对意见,RMI就是让你在服务器端发布一个Remote Object,然后通过RMI协议进行远程调用,我以前的项目就做->发布一个Remote Object到JNDI上,然后lookup,进行远程方法调用! 而且这个Remote Object里面所包含的东西都是可序列化的.

最后,如果这种远程lookup SesssionFactory的方法不行的,我对[在Weblogic上配置Hibernate的SF到JNDI],[Struts结合Hibernate]能够正常运行产生一些疑问: 正常运行是因为 lookup SF的serverlet或JavaBean与绑定到JNDI上的SF都共同位于同一个Container中,所以lookup SF的操作不是远程的,所以无需序列化(直接内存调用) 吗?

你把JNDI和远程对象混为一谈了吧？从来都没有人说过从JNDI上查出来的对象一定是支持远程调用的吧？

JNDI的Context本质上就是一个映射的集合，集合里面的每个映射都是一个名称映射一个对象。

[code:1]name --> object
......
name --> object [/code:1]

如果这个object本来就是支持远程调用的，那么你lookup出来自然也是支持的，如果本来就不支持远程调用，你放不放到JNDI里面都没有区别。Hibernate的SessionFactory本来就不一定非放到JNDI中不可，也有很多人喜欢写一个Singleton的类来获取，放到JNDI里面比较有利于在EJB中使用SessionFactory。

"JNDI的Context本质上就是一个映射的集合，集合里面的每个映射都是一个名称映射一个对象"
这句话没错!

JNDI说白了就是提供一个网络目录服务,让你可以通过lookup可以找到网络上可用的对象

"你把JNDI和远程对象混为一谈了吧？从来都没有人说过从JNDI上查出来的对象一定是支持远程调用的吧？ "
这点我没有搞错!!! 但是有一点不要搞错啊,能够绑定到JNDI上的对象有个起码的要求,就是该对象必须实现序列化,而且该对象里面所包含的对象也要序列化,要不在网络上传输是时就会出错.例如Vector类是实现了序列化的,如果要让一个Vector对象在网络上可以传输,该Vector对象内的add进去的对象也 必须是可序列化的,否则出错!
再来解析一下RMI的一些知识: 绑定到JNDI上的对象需要序列化外, 如果该对象实现了Remote接口,那么客户端lookup到一个对象后,这个对象实际上是服务器对象的一个引用,是"引用传递",你修改了该对象,服务器端的对象也会改变, 如果绑定到JNDI上的对象没有实现Remote接口,那么lookup到的对象是服务器端对象的一个拷贝("值传递"),修改了该对象不会对服务器端对象造成影响!
好了,现在有两个疑问:
1.SessionFactory实现了序列化,但是里面所包含的对象都实现了序列化了吗?如果没有,放到JNDI上,让客户端去lookup,让SessionFactory在网络上传输,就会出错!
2.为什么[在Weblogic上配置Hibernate的SF到JNDI],[Struts结合Hibernate]上介绍的方式却可以运行呢,我不得不提醒: SF根本没有在网络上传输,记得里面lookup的方法吗? 它用的是ctx.lookup(......),根本没有加上ip地址,端口,provider等信息, 也就是根本没有进行过网络查找和传输, 因为SF绑定到的JNDI的Service和lookup SF的servlet是位于同一个app server,位于同一个JVM环境,在同一个内存中,无需远程传输,所以,用[在Weblogic上配置Hibernate的SF到JNDI],[Struts结合Hibernate]里面的方式lookup到的SF实际上是本机上的SF, 如果你lookup其它机器的SF,就有可能出错(如果SF内的所有对象都是可序列化的就不会有问题) . 现在我的问题就是,把SF绑定到JNDI上,供本机上(同一个jvm)的其它对象lookup是可行的,但是要注意问题的根本! 所以我觉得先前的回答没有回答到点子上!

我觉得你对JNDI的绑定的解释是错误的。实际上JNDI的绑定就是很简单的：name ---> ojbect ，和object本身是不是实现Remote接口没有关系，也不存在什么“引用传递”和“值传递”的区别。如果一定要说，那么全部都是引用传递。其实对于像EJB这样的支持远程调用的Object来说，JNDI上绑定的并不是EJB的Bean本身，而是Bean的RemoteObjectImpl，就是Bean的远程接口实现类。这一点如果是用Weblogic的话，很容易在Console里面查看JNDI Tree上看出来。

JNDI只是提供了对象的远程查找能力。至于你从其他的JVM通过JNDI找到这个对象之后，这个对象究竟能不能RMI，那么就和JNDI毫无关系了。实际上就算是支持RMI的对象，你当初绑定到JNDI上的也不是对象本身，而是对象的远程接口实现类。单纯从这一点来说，JNDI里面直接查找出来的对象都不可能直接RMI。

如何能让远程lookup到的SessionFactory支持RMI呢？那么你就需要为SessionFactory写stub类和skeleton类，并且把这个SessionFactory本身注册到RMI Registery上去。然后把SessionFactory_stub类绑定到JNDI上(而不是绑定SessionFactory)，让远程的机器通过JNDI查找到的是SessionFactory_stub，而不是SessionFactory本身，然后通过SessionFactory_stub来远程操纵SessionFactory。

如果绑定到JNDI上的不是SessionFactory_stub，而是SessionFactory本身，那么很显然是不支持RMI的。可以通过JNDI远程查找到一个对象并不意味找到的对象一定就支持远程访问。所以绑定到JNDI上的SessionFactory，并不能够提供远程访问功能，从其他的JVM可以通过lookup查找到SessionFactory，但是不能够远程访问。

实际上把Hibernate SessionFactory绑定到JNDI的初衷也并不是让远程机器来访问的，实际就是提供给同一JVM内的对象访问的，准确的来说，就是给同一JVM内的EJB来访问的。因为在EJB的环境下，用传统的Singleton方式获取SessionFactory有可能会失效，用JNDI的方式比较保险，可以确保只创建一个SessionFactory，都可以访问到这一个SessionFactory。

谢谢robbin!