PDA

View Full Version : Session-in-view + transaction interceptor



summer
Sep 19th, 2004, 06:25 PM
Hi I am trying to get up and running with webwork + spring + hibernate

I've got everything working working with template callbacks for transactions but after reading about source level meta data i'd really like to use that
I've basicly set up everything like this



<bean id="transactionManager" class="org.springframework.orm.hibernate.HibernateTransac tionManager">
<property name="sessionFactory">
<ref local="sessionFactory"/>
</property>
</bean>

<bean id="autoproxy" class="org.springframework.aop.framework.autoproxy.Defaul tAdvisorAutoProxyCreator">
<property name="proxyTargetClass">
<value>true</value>
</property>
</bean>

<bean id="transactionAttributeSource" class="org.springframework.transaction.interceptor.Attrib utesTransactionAttributeSource" autowire="constructor" />

<bean id="transactionInterceptor" class="org.springframework.transaction.interceptor.Transa ctionInterceptor" autowire="byType" />


The action class looks like this

<bean id="Someaction" name=" ... " class=" ... " singleton="false">
....
</bean>


The non singleton Someaction action class has

@@org.springframework.transaction.interceptor.Defa ultTransactionAttribute()

on top, the attributes compiler generates the classes all fine

I am using the session in view filter which means FlushMode.NEVER is set on the session and you should preferably use middle tier transactions

Which I thought I'd set up with all of the above but I am still getting Write operations are not allowed exceptions

So I'd like to know

1. Should the transaction interceptor commit / flush the session or do you need to do that some other way

2. If it should do that does anyone have a clue as to why it's not working in my setup

3. is there a way to detect if your method is being adviced

summer
Sep 20th, 2004, 04:16 PM
Well I did some more tests and did a little reading and it turns out that spring aop is quite a bit different from for instance aspect j in that it creates proxy objects that sit infront of the actual object, so interceptors on methods only work when called from the outside

so say you have an object




public Object someObject&#40;&#41; &#123;

/** @@org.springframework.transaction.interceptor.Defa ultTransactionAttribute&#40;&#41;
*/
private void doSomething&#40;&#41; &#123;
....
&#125;

public void execute&#40;&#41; &#123;
doSomething&#40;&#41;
&#125;


&#125;

and you call execute you really call execute on the proxy, which would call execute on the actual object, but doSomething is called behind the proxy do doesn't get intercepted...

That's basically what's going on with my webwork methods.. and it's anoying I don't really think there is a good solution to this problem apart from doing all transactions in an applicationservice or using template callbacks instead

summer
Sep 20th, 2004, 05:16 PM
CGLIB proxying works by generating a subclass of the target class at runtime. Spring configures this generated
subclass to delegate method calls to the original target: the subclass is used to implement the Decorator pattern,
weaving in the advice.


hmmm if that is correct it *SHOULD* work... I am pretty confused now