Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-07-29 17:20:55
|
Colin, As I was just discussing the issue with a colleague of mine, and as = you're known to not like the Open Session in View pattern ;-) What do you think regarding this "deferred close" mode for = OpenSessionInViewFilter/Interceptor that I've introduced a while ago? = That combination of correct transactional semantics plus lazy loading in = the view is a quite nice way to avoid the drawbacks of the classic = OpenSessionInViewFilter (what's now called "single session" mode). It = should never cause side effects but still allow for flexible lazy = loading. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of j=FCrgen h=F6ller [werk3AT] Sent: Friday, July 09, 2004 7:39 PM To: spr...@li... Subject: [Springframework-developer] New deferred close mode for OpenSessionInViewFilter/Interceptor Due to numerous recent requests in that direction, I've implemented a = new mode for OpenSessionInViewFilter/Interceptor, as alternative to a = single session per request:=20 Each data access operation respectively transactions uses its own = Hibernate Session (like when not using Open Session in View). Each of = those sessions will be registered for deferred close, though, actually = processed at request completion. This does allow for lazy loading with = each of those sessions, but you won't get a single first-level cache for = the entire request, as there can be multiple Sessions.=20 OpenSessionInViewFilter/Interceptor still uses a single session per = request by default, but allows to activate deferred close mode instead = by specifying "singleSession"=3D"false" as init-param respectively bean = property.=20 Juergen =20 ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20 digital self defense, top technical experts, no vendor pitches,=20 unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: <jue...@we...> - 2004-07-30 08:44:14
|
The nicest scenario is if you do *not* use Open Session in View now but = just have classic per-transaction sessions. In that case, if you want to = add lazy loading, simply plug in OpenSessionInViewFilter/Interceptor in = "deferred close" mode, and the semantics will be exactly the same as = before - just with the additional chance to lazy load until view = rendering has been completed. =20 Compared to plugging in OpenSessionInViewFilter in "single session" = mode, which changes your semantics quite severely, the "deferred close" = mode is a great benefit, I think. =20 The only disadvantage that I can see is that you won't get a = request-scoped first-level cache, which a single Hibernate session would = give you. So it's essentially about a tradeoff: clean transactional = semantics (which does not allow for a request-scoped cache) plus lazy = loading, or a request-scoped cache (which incurs unclean transactional = semantics but avoids rebuilding of object graphs) plus lazy loading? =20 It's also worth noting that rebuilding persistent object graphs for each = transaction is not that inefficient if you use lazy loading heavily: = You'll just get the actually needed object graph anyway, thus the = reloading respectively rebuilding overhead is limited. =20 Since Hibernate 2.1.4, the latter even applies if your entire object = graphs are cached in the second-level cache: Hibernate does not = materialize lazy parts of the object graph now, even if they are = available from the second-level cache. This is quite a gain in = efficiency if your object graphs are very large, where even rebuilding = from the second-level cache incurs a significant overhead. They silently = changed this between Hibernate 2.1.3 and 2.1.4, but at least into the = right direction :-) =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Colin Sampaleanu Gesendet: Do 29.07.2004 19:58 An: spr...@li... Betreff: Re: [Springframework-developer] New deferred close mode for = OpenSessionInViewFilter/Interceptor I think this is cool and potentially pretty useful, in terms of simplifying lazy relation handling. Now somebody using Open Session in View now can not automatically swap out to this variant though, since if they are depending on sharing the same objects between different invocations down to transactional services, they are going to get exceptions from Hibernate when it sees that the objects are from different sessions. On the other hand, this is great for somebody that does want to call down once to a use-case defined service which retturns a graph of data, and now doesn't have to worry about touching all lazy relationships that might be needed. This actually brings the Hibernate scenario closer in line to what you can do with JDO 2 and handling of non-transactional graphs. Colin j=FCrgen h=F6ller [werk3AT] wrote: >Colin, > >As I was just discussing the issue with a colleague of mine, and as = you're known to not like the Open Session in View pattern ;-) > >What do you think regarding this "deferred close" mode for = OpenSessionInViewFilter/Interceptor that I've introduced a while ago? = That combination of correct transactional semantics plus lazy loading in = the view is a quite nice way to avoid the drawbacks of the classic = OpenSessionInViewFilter (what's now called "single session" mode). It = should never cause side effects but still allow for flexible lazy = loading. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of j=FCrgen h=F6ller [werk3AT] >Sent: Friday, July 09, 2004 7:39 PM >To: spr...@li... >Subject: [Springframework-developer] New deferred close mode for >OpenSessionInViewFilter/Interceptor > > >Due to numerous recent requests in that direction, I've implemented a = new mode for OpenSessionInViewFilter/Interceptor, as alternative to a = single session per request: > >Each data access operation respectively transactions uses its own = Hibernate Session (like when not using Open Session in View). Each of = those sessions will be registered for deferred close, though, actually = processed at request completion. This does allow for lazy loading with = each of those sessions, but you won't get a single first-level cache for = the entire request, as there can be multiple Sessions. > >OpenSessionInViewFilter/Interceptor still uses a single session per = request by default, but allows to activate deferred close mode instead = by specifying "singleSession"=3D"false" as init-param respectively bean = property. > >Juergen > > ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: Colin S. <col...@ex...> - 2004-07-29 17:59:55
|
I think this is cool and potentially pretty useful, in terms of simplifying lazy relation handling. Now somebody using Open Session in View now can not automatically swap out to this variant though, since if they are depending on sharing the same objects between different invocations down to transactional services, they are going to get exceptions from Hibernate when it sees that the objects are from different sessions. On the other hand, this is great for somebody that does want to call down once to a use-case defined service which retturns a graph of data, and now doesn't have to worry about touching all lazy relationships that might be needed. This actually brings the Hibernate scenario closer in line to what you can do with JDO 2 and handling of non-transactional graphs. Colin jürgen höller [werk3AT] wrote: >Colin, > >As I was just discussing the issue with a colleague of mine, and as you're known to not like the Open Session in View pattern ;-) > >What do you think regarding this "deferred close" mode for OpenSessionInViewFilter/Interceptor that I've introduced a while ago? That combination of correct transactional semantics plus lazy loading in the view is a quite nice way to avoid the drawbacks of the classic OpenSessionInViewFilter (what's now called "single session" mode). It should never cause side effects but still allow for flexible lazy loading. > >Juergen > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of jürgen höller [werk3AT] >Sent: Friday, July 09, 2004 7:39 PM >To: spr...@li... >Subject: [Springframework-developer] New deferred close mode for >OpenSessionInViewFilter/Interceptor > > >Due to numerous recent requests in that direction, I've implemented a new mode for OpenSessionInViewFilter/Interceptor, as alternative to a single session per request: > >Each data access operation respectively transactions uses its own Hibernate Session (like when not using Open Session in View). Each of those sessions will be registered for deferred close, though, actually processed at request completion. This does allow for lazy loading with each of those sessions, but you won't get a single first-level cache for the entire request, as there can be multiple Sessions. > >OpenSessionInViewFilter/Interceptor still uses a single session per request by default, but allows to activate deferred close mode instead by specifying "singleSession"="false" as init-param respectively bean property. > >Juergen > > |
|
From: James C. <jim...@do...> - 2004-07-29 19:46:25
|
Can you guys elaborate on this deferred close mode a bit more? Did I = miss an earlier posting? We have done a ton of experimenting with Open Session In View and = dropped it in favor of a service layer pattern. There are a bunch of tradeoffs to either approach and I am interested in learning about a potential third approach. > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...] On = Behalf > Of Colin Sampaleanu > Sent: Thursday, July 29, 2004 1:59 PM > To: spr...@li... > Subject: Re: [Springframework-developer] New deferred close mode for > OpenSessionInViewFilter/Interceptor >=20 > I think this is cool and potentially pretty useful, in terms of > simplifying lazy relation handling. Now somebody using Open Session in > View now can not automatically swap out to this variant though, since = if > they are depending on sharing the same objects between different > invocations down to transactional services, they are going to get > exceptions from Hibernate when it sees that the objects are from > different sessions. On the other hand, this is great for somebody that > does want to call down once to a use-case defined service which = retturns > a graph of data, and now doesn't have to worry about touching all lazy > relationships that might be needed. This actually brings the Hibernate > scenario closer in line to what you can do with JDO 2 and handling of > non-transactional graphs. >=20 > Colin >=20 > j=FCrgen h=F6ller [werk3AT] wrote: >=20 > >Colin, > > > >As I was just discussing the issue with a colleague of mine, and as > you're known to not like the Open Session in View pattern ;-) > > > >What do you think regarding this "deferred close" mode for > OpenSessionInViewFilter/Interceptor that I've introduced a while ago? = That > combination of correct transactional semantics plus lazy loading in = the > view is a quite nice way to avoid the drawbacks of the classic > OpenSessionInViewFilter (what's now called "single session" mode). It > should never cause side effects but still allow for flexible lazy = loading. > > > >Juergen > > > > > >-----Original Message----- > >From: spr...@li... > >[mailto:spr...@li...]On = Behalf > >Of j=FCrgen h=F6ller [werk3AT] > >Sent: Friday, July 09, 2004 7:39 PM > >To: spr...@li... > >Subject: [Springframework-developer] New deferred close mode for > >OpenSessionInViewFilter/Interceptor > > > > > >Due to numerous recent requests in that direction, I've implemented a = new > mode for OpenSessionInViewFilter/Interceptor, as alternative to a = single > session per request: > > > >Each data access operation respectively transactions uses its own > Hibernate Session (like when not using Open Session in View). Each of > those sessions will be registered for deferred close, though, actually > processed at request completion. This does allow for lazy loading with > each of those sessions, but you won't get a single first-level cache = for > the entire request, as there can be multiple Sessions. > > > >OpenSessionInViewFilter/Interceptor still uses a single session per > request by default, but allows to activate deferred close mode instead = by > specifying "singleSession"=3D"false" as init-param respectively bean > property. > > > >Juergen > > > > >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes = on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source = Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer |
|
From: James C. <jim...@do...> - 2004-08-03 13:24:54
|
When using the following bean definition:
<bean id="petStore" class=
"org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager">
<ref bean="transactionManager"/>
</property>
<property name="target">
<ref bean="petStoreTarget"/>
</property>
<property name="transactionAttributes">
<props>
<prop key="insert*">PROPAGATION_REQUIRED,-MyCheckedException</prop>
<prop key="update*">PROPAGATION_REQUIRED</prop>
<prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
</props>
</property>
</bean>
What is the significance of the readOnly attribute in the property list? Is
this just a "hint" passed to certain transaction managers that may be able
to optimize these methods, or does it result in a specific, repeatable
behavior?
|
