Open Session In View 探討
它有兩種配置方式OpenSessionInViewInterceptor和OpenSessionInViewFilter(具體參看SpringSide),功能相同,只是一個在web.xml配置,另一個在application.xml配置而已。
Open Session In View在request把session繫結到當前thread期間一直保持hibernate session在open狀態,使session在request的整個期間都可以使用,如在View層裡PO也可以lazy loading資料,如 ${ company.employees }。當View 層邏輯完成後,才會通過Filter的doFilter方法或Interceptor的postHandle方法自動關閉session。
OpenSessionInViewInterceptor配置
<bean name="openSessionInViewInterceptor" class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="interceptors">
<list>
<ref bean="openSessionInViewInterceptor"/>
</list>
</property>
<property name="mappings">
...
</property>
</bean> ...
</beans>
OpenSessionInViewFilter配置
...
<filter>
<filter-name>hibernateFilter</filter-name>
<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter </filter-class>
<!-- singleSession預設為true,若設為false則等於沒用OpenSessionInView -->
<init-param>
<param-name>singleSession</param-name>
<param-value>true</param-value>
</init-param>
</filter>
...
<filter-mapping>
<filter-name>hibernateFilter</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>
...
</web-app>
很多人在使用OpenSessionInView過程中提及一個錯誤:
看看OpenSessionInViewFilter裡的opensession方法
Session session = SessionFactoryUtils.getSession(sessionFactory, true);
session.setFlushMode(FlushMode.NEVER);
return session;
}
可以看到OpenSessionInViewFilter在getSession的時候,會把獲取回來的session的flush mode 設為FlushMode.NEVER。然後把該sessionFactory繫結到TransactionSynchronizationManager,使request的整個過程都使用同一個session,在請求過後再接除該sessionFactory的繫結,最後closeSessionIfNecessary根據該session是否已和transaction繫結來決定是否關閉session。在這個過程中,若HibernateTemplate 發現自當前session有不是readOnly的transaction,就會獲取到FlushMode.AUTO Session,使方法擁有寫許可權。
也即是,如果有不是readOnly的transaction就可以由Flush.NEVER轉為Flush.AUTO,擁有insert,update,delete操作許可權,如果沒有transaction,並且沒有另外人為地設flush model的話,則doFilter的整個過程都是Flush.NEVER。所以受transaction保護的方法有寫許可權,沒受保護的則沒有。
採用spring的事務宣告,使方法受transaction控制
<property name="transactionManager" ref="transactionManager"/>
<property name="proxyTargetClass" value="true"/>
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
<prop key="save*">PROPAGATION_REQUIRED</prop>
<prop key="add*">PROPAGATION_REQUIRED</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="remove*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<bean id="userService" parent="baseTransaction">
<property name="target">
<bean class="com.phopesoft.security.service.impl.UserServiceImpl"/>
</property>
</bean>
對於上例,則以save,add,update,remove開頭的方法擁有可寫的事務,如果當前有某個方法,如命名為importExcel(),則因沒有transaction而沒有寫許可權,這時若方法內有insert,update,delete操作的話,則需要手動設定flush model為Flush.AUTO,如
session.save(user);
session.flush();
儘管Open Session In View看起來還不錯,其實副作用不少。看回上面OpenSessionInViewFilter的doFilterInternal方法程式碼,這個方法實際上是被父類的doFilter呼叫的,因此,我們可以大約瞭解的OpenSessionInViewFilter呼叫流程: request(請求)->open session並開始transaction->controller->View(Jsp)->結束transaction並close session.
一切看起來很正確,尤其是在本地開發測試的時候沒出現問題,但試想下如果流程中的某一步被阻塞的話,那在這期間connection就一直被佔用而不釋放。最有可能被阻塞的就是在寫Jsp這步,一方面可能是頁面內容大,response.write的時間長,另一方面可能是網速慢,伺服器與使用者間傳輸時間久。當大量這樣的情況出現時,就有連線池連線不足,造成頁面假死現象。
Open Session In View是個雙刃劍,放在公網上內容多流量大的網站請慎用。
相關文章
- open session in viewSessionView
- 請教open session in viewSessionView
- 關於open session in view,想在此請教!SessionView
- open session in view引起的事務問題SessionView
- hibernate open session in view 丟擲異常解決方法SessionView
- sencha touch 檢視(view) show與hide事件探討ViewIDE事件
- 探討Web開發中的Session儲存與管理WebSession
- SAP MM 實施專案裡Open PO 遷移思路探討
- Promise探討Promise
- 深入探討 UndefinedUndefined
- IsPostBack深入探討
- su - root could not open sessionSession
- session_max_open_filesSession
- Discussion Session:鎖存型讀出放大器(Sense Amplifier)電路探討Session
- px em rem 探討REM
- with as探討時小插曲
- Oracle Stream 深入探討Oracle
- JdonFramework程式碼探討Framework
- SESSION_CURSOR_CACHE open_cursorsSession
- 深入探討單例模式單例模式
- cassandra查詢效率探討
- 前端工程架構探討前端架構
- AdobeFlashLite探討
- Oracle 技術探討3Oracle
- Oracle 技術探討2Oracle
- Oracle 技術探討1Oracle
- 責任鏈模式探討模式
- JavaScript原型鏈汙染探討JavaScript原型
- 解決“su: cannot open session: Permission denied”Session
- open_cursors與session_cached_cursorsSession
- su的時候報:could not open sessionSession
- Not Able To Open Forms Session After Cloning.ORMSession
- 深入探討ROP 載荷分析
- SQL優化器探討(zt)SQL優化
- Netty URL路由方案探討Netty路由
- Springboot 加密方案探討Spring Boot加密
- oracle 雙機部署模式探討Oracle模式
- 深入探討JavaScript函式物件JavaScript函式物件