首先谈一下对session对象在web开发中的创建以及sessionId生成并返回客户端的运行机制.
session对象当客户端首次访问时,创建一个新的session对象.并同时生成一个sessionId,并在此次响应中将sessionId以响应报文的方式些回客户端浏览器内存或以重写url方式送回客户端,来保持整个会话,只要sever端的这个session对象没有销毁,以后再调用request.getSession() 时就直接根据客户端的sessionId来检索server端生成的session对象并返回,不会再次去新建,除非根据此sessionId没有检索到 session对象.
下面是在IE下测试,因为IE6.0的一个BUG就是IE的隐私设置即使是阻止所有cookie时,也还是会以会话cookie来保存sessionId.所以下面都是以会话cookie来讨论的,
(1)在server没有关闭,并在session对象销毁时间内,当客户端再次来请求server端的servlet或jsp时, 将会将在第一次请求时生成的sessionId并附带在请求信息头中并向server端发送,server端收到sessionId后根据此 sessionId会去搜索(此过程是透明的)server对应的session对象并直接返回这个session对象,此时不会重新去建立一个新的 session对象.
(2)当server关闭(之前产生的session对象也就消亡了),或session对象过了其销毁时间后, 浏览器窗口不关,并在本浏览器窗口再次去请求sever端的servlet和jsp时,此时同样会将sessionId(server关闭或 session销毁时生成的sessionId)发送到server端,server根据sessionId去找其对应的session对象,但此时 session对象已经不存在,此时会重新生成一个新的session对象,并生成新的sessionId并同样将这个新生成的sessionId以响应报文的形式送到浏览器内存中.
(3)当server没有关闭,并session对象在其销毁时间内,当请求一个jsp页面回客户端后, 关闭此浏览器窗口,此时其内存中的sessionId也就随之销毁,在重新去请求sever端的servlet或jsp时,会重新生成一个 sessionId给客户端浏览器,并存在浏览内存中.
上面的理论在servlet中测试都是成立的,下面谈一下在struts框架下进行上面的测试时的不同的地方.
先简要说下测试程序的流程:
客户端请求index.do--->进入server端的IndexAction--->转向login.jsp页面----->请求login.do----->进入server端的LoginAction.
首先说明:IndexAction中没有去产生session对象,login.jsp中设置.
(1)环境servlet + jsp:
在sevlet+jsp测试跟踪时,在index.do进入IndexAction后转向login.jsp时,此时浏览器内存中是没有会话cookie的,那么在login.jsp上请求login.do进入LoginAction后,用request.getCookies()测试时,其值是为null的!结果是稳合的,因为从始置终没有产生过session嘛!
(2)环境struts + jsp:
在struts+jsp测试跟踪时,跟上面的流程一样,开始想结果也应该是一样的,但经过调试后发现结果却不是所想的那样.在login.do进入 LoginActoin后用,用request.getCookies()测试时,发现其值不为null,即其有name和value,开始很不理解,因为根本就没有创建过session对象,哪来的会话cookie值呢.但是结果有,那么想着此时浏览器内存中也就应该有会话cookie,问题就在这里! 从哪里来的?
后来经过仔细考虑后,想到struts中的特点,我们自己写的Action类是继承struts的Action的,而且之前是经过struts的中央控制器ActionServlet来控制转向的,所以我想肯定是在程序进入我自己写的IndexAction之前, struts框架中的代码肯定已经创建了session对象并已经生成了sessionId.于是就找到相关书籍查看了ActionServlet工作流程以及调用哪些类,看了之后果然在其中看到了HttpSession session = request.getSession();这样一句话!于是答案也就明了了.
大家知道struts的ActionServlet类中在接收到我们客户端的请求(*.do)后(之前会做一系列初始化工作),并不是直接去处理我们的请求并调用相应的Action(我们写的如 IndexAction),而是将处理工作交给RequestProcessor类,其process方法中会调用一系列的方法来完成相应的请求处理和转向操作.其中有一个方法引起了我的关注,就是processLocale()方法.
Struts框架:RequestProcess类中的processLocale()方法原型如下:
程序代码:
protected void processLocale(HttpServletRequest request,
HttpServletResponse response) {
// Are we configured to select the Locale automatically?
if (!moduleConfig.getControllerConfig().getLocale()) {
return;
}
// Has a Locale already been selected?
HttpSession session = request.getSession();
if (session.getAttribute(Globals.LOCALE_KEY) != null) {
return;
}
// Use the Locale returned by the servlet container (if any)
Locale locale = request.getLocale();
if (locale != null) {
if (log.isDebugEnabled()) {
log.debug(" Setting user locale '" + locale + "'");
}
session.setAttribute(Globals.LOCALE_KEY, locale);
}
}
此类在struts-config.xml配置文件中有对应的配置项: < controller locale="true">< /controller> 其缺省状态locale属性的值为true,也就会调用processLocale方法,并在第一次请求时创建session对象和生成 sessionId.但改为false后,在第一次请求到达ActionServlet后不会调用processLocale方法,也就不会生成 session对象了。
结果也就出来了，在struts应用中,*.do到达server端后经过ActionServlet后转想我们自己写的IndexAction之前, < controller locale="true">< /controller>(缺省状态) 时,就已经产生了session对象和sessionId,这是struts框架类中生成的,即使我们在IndexAction中写上 HttpSession session = request.getSession();其也是RequestProcess类中的processLocale()方法生成的,此时其session 的isNew也还是true,因为还没有返回客户端,其是新创建的,那么按照上面的流程,当在login.jsp上通过login.do进入 LoginAction后,其request.getCookies()固然也就有值了!并且其值是RequestProcess类中的 processLocale()方法产生session对象时生成的.
如果我们在struts-config.xml中加上< controller locale="false">< /controller> 时,此时如果再根据上面的流程来跟踪程序,并在LoginAction用request.getCookies()测试时,其值是为null的,当然在 IndexAction写上HttpSession session = request.getSession();时其是进入IndexAction时新创建的,isNew也是true。
察看了JBOSS的源代码，命名服务器抛出的这个异常分析如下
java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1639)
at java.io.ObjectOutputStream$BlockDataOutputStream.setBlockDataMode(ObjectOutputStream.java:1548)
at java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1146)
at java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1100)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1241)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052)
at java.io.ObjectOutputStream.writeFatalException(ObjectOutputStream.java:1355)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:281)
上述异常是由于这样的原因造成的：
1、 客户端进行查找是NamingContext会建立到命名服务器的Socket连接。（此连接是带读取超时的！）
2、 服务器接收了客户端的连接，使客户端可以继续向下运行。于是客户端运行到ObjectInputStream的readObject处，并等待。此时，客户端是想要得到NamingServer的stub。
3、 服务端由于线程繁忙，迟迟不能将客户端需要的stub写入ObjectOutputStream。于是客户端等待超时，然后客户端抛出异常。如果此查找操作是在登录操作，客户在登录失败后选择推出程序。则Socket被关闭。
4、 服务端闲下来后调用ObjectOutputStream的writeObject方法，此时由于客户端Socket关闭，最终抛出上述异常。
这是我们公司的一个牛人分析的，后来察看了JMS也存在类似问题。另：JBOSS的源代码质量不高，JNDI中存在socket未关闭的情况，JMS代码中socket用法也很不规范。大家小心了
Hibernate构架应用中常用保存方式区别
Tag：数据库 pda ie hibernate
下一页 1 2
hibernate对于对象的保存提供了太多的方法，他们之间有很多不同，这里细说一下，以便区别：
一、预备知识：
在所有之前，说明一下，对于hibernate，它的对象有三种状态，transient、persistent、detached
下边是常见的翻译办法：
transient：瞬态或者自由态
persistent：持久化状态
detached：脱管状态或者游离态
脱管状态的实例可以通过调用save（）、persist（）或者saveOrUpdate（）方法进行持久化。
持久化实例可以通过调用 delete（）变成脱管状态。通过get（）或load（）方法得到的实例都是持久化状态的。
脱管状态的实例可以通过调用 update（）、0saveOrUpdate（）、lock（）或者replicate（）进行持久化。
save（）和persist（）将会引发SQL的INSERT，delete（）会引发SQLDELETE，而update（）或merge（）会引发SQLUPDATE.对持久化（persistent）实例的修改在刷新提交的时候会被检测到，它也会引起 SQLUPDATE.saveOrUpdate（）或者replicate（）会引发SQLINSERT或者UPDATE
二、save 和update区别
把这一对放在第一位的原因是因为这一对是最常用的。
save的作用是把一个新的对象保存
update是把一个脱管状态的对象保存
三、update 和saveOrUpdate区别
这个是比较好理解的，顾名思义，saveOrUpdate基本上就是合成了save和update引用hibernate reference中的一段话来解释他们的使用场合和区别。
通常下面的场景会使用update（）或saveOrUpdate（）：
程序在第一个session中加载对象
该对象被传递到表现层
对象发生了一些改动
该对象被返回到业务逻辑层
程序调用第二个session的update（）方法持久这些改动
saveOrUpdate（）做下面的事：
如果对象已经在本session中持久化了，不做任何事
如果另一个与本session关联的对象拥有相同的持久化标识（identifier），抛出一个异常
如果对象没有持久化标识（identifier）属性，对其调用save（）
如果对象的持久标识（identifier）表明其是一个新实例化的对象，对其调用save（）
如果对象是附带版本信息的（通过或） 并且版本属性的值表明其是一个新实例化的对象，save（）它。
四、persist和save区别
这个是最迷离的一对，表面上看起来使用哪个都行，在hibernate reference文档中也没有明确的区分他们。
这里给出一个明确的区分。（可以跟进src看一下，虽然实现步骤类似，但是还是有细微的差别）
1.persist把一个瞬态的实例持久化，但是并"不保证"标识符被立刻填入到持久化实例中，标识符的填入可能被推迟到flush的时间。
2.persist"保证"，当它在一个transaction外部被调用的时候并不触发一个Sql Insert，这个功能是很有用的，当我们通过继承Session/persistence context来封装一个长会话流程的时候，一个persist这样的函数是需要的。
3.save"不保证"第2条，它要返回标识符，所以它会立即执行Sql insert，不管是不是在transaction内部。
五、saveOrUpdateCopy，merge和update区别
首先说明merge是用来代替saveOrUpdateCopy的,然后比较update和merge，update的作用上边说了，这里说一下merge的作用。
如果session中存在相同持久化标识（identifier）的实例，用用户给出的对象的状态覆盖旧有的持久实例
如果session没有相应的持久实例，则尝试从数据库中加载，或创建新的持久化实例，最后返回该持久实例
用户给出的这个对象没有被关联到session上，它依旧是脱管的
重点是最后一句：
当我们使用update的时候，执行完成后，我们提供的对象A的状态变成持久化状态
但当我们使用merge的时候，执行完成，我们提供的对象A还是脱管状态，hibernate或者new了一个B，或者检索到一个持久对象，并把我们提供的对象A的所有的值拷贝到这个B，执行完成后B是持久状态，而我们提供的A还是托管状态。
六、flush和update区别
这两个的区别好理解
update操作的是在脱管状态的对象，而flush是操作的在持久状态的对象。
默认情况下，一个持久状态的对象是不需要update的，只要你更改了对象的值，等待hibernate flush就自动保存到数据库了。hibernate flush发生再几种情况下：
1.调用某些查询的时候
2.transaction commit的时候
3.手动调用flush的时候
七、lock和update区别
update是把一个已经更改过的脱管状态的对象变成持久状态
lock是把一个没有更改过的脱管状态的对象变成持久状态
对应更改一个记录的内容，两个的操作不同：
update的操作步骤是：
更改脱管的对象->调用update
lock的操作步骤是：
调用lock把对象从脱管状态变成持久状态——>更改持久状态的对象的内容——>等待flush或者手动flush