struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rene Gielen <gie...@it-neering.net>
Subject Re: @Transactional Spring Annotation in a Struts2 Action does not work
Date Fri, 08 May 2009 01:41:02 GMT
You should consider to have a look into the paramsPrepareParams pattern 
(see struts-default.xml for a brief description) and to write and use a 
TransactionInterceptor. The latter one gives you the same cross cutting 
TX approach you want from your @Transational annotation, but in addition 
to that it supports lazy loading of hibernate proxied properties when 
the view is rendered. Basically, this is similar to the 
OpenSessionInView Hibernate pattern.

Jeroen De Ridder schrieb:
> Hi Dustin,
> 
> Yes, I do require the ability to be able to manually set transaction 
> boundaries from controller code. The main reason is because Hibernate 
> updates database records when a persistent object changes state during a 
> transaction. It picks up on the changes made to the object when the 
> transaction is committed and persists them to the database. Using the 
> service layer to do that wouldn't really make sense because you would 
> have to create methods for every set of changed properties you require. 
> And even if you did that, you still wouldn't be able to combine the 
> transaction with any other controller logic.
> 
> Basically, I try to use service layer calls as much as possible without 
> an explicit transaction created in the controller if not necessary. 
> Updates to persistent instances virtually always require the controller 
> to start a transaction though, for the reason outlined above. So for 
> example, I have a service for products which has a method to grab a 
> product instance by ID. If all I need is the product instance to read 
> some stuff from, I'll do:
> 
> Product p = productService.getProduct(myProductId);
> 
> Notice that I didn't create a transaction in the controller code, so the 
> service method will create one for itself, and that's fine. When I 
> update a product however, I'll do this:
> 
> txr.execute(new TransactionalExecution(){
>    public void execute() {
>                         Product p = productService.getProduct(myProductId);
>        if(p == null) throw new MyException("No such product exists!");
>             p.setName(name);
>    p.setPrice(price);
>    p.setColor(color);
>         }
> });
> 
> The reason here is that I need the product instance to be updated with 
> my Struts 2 parameter data (name, price and color), so I need to change 
> its properties during a transaction. I think you'll agree that it really 
> doesn't make sense to create a service layer method updateProduct(name, 
> price, color) or something like that for every possible combination of 
> properties you want to change. As I mentioned before, the controller 
> logic that updates the instance's properties can use arbitrary service 
> layer functionality all within the same transaction, courtesy of 
> propagation=REQUIRED. I think this makes for pretty clear and easy to 
> understand code.
> 
> Does this answer your question?
> 
>> Jeroen,
>>
>> This setup is so that you can initiate and control the properties of the
>> transaction from the controller, if that is a pattern you require?
>>
>> Do you do this for all your calls to the service layer from 
>> controllers, and
>> how is it better/different from a calling a service method annotated with
>> @Transactional(propagation=Propagation.REQUIRED) normally from the
>> controller?   Is it just so you can control the propagation 
>> characteristics? 
>> It seems like an interesting pattern, I am just wondering how it is used.
>>
>> Jeroen De Ridder wrote:
>>  
>>> I'll agree that a service layer alone won't cut it, simply because of 
>>> the way JPA/Hibernate works. Updating an instance for example is just 
>>> something that doesn't belong in a service. I'm by no means an expert 
>>> of best practices in JPA/Hibernate and Spring, but I've found a 
>>> combination of services and anonymous runner interface instances to 
>>> work quite well.
>>>
>>> Basically, the idea is that you create a bunch of services to do 
>>> routine stuff to improve code clarity and avoid code duplication in 
>>> your actions. You'd mark these services with propagation=REQUIRED, so 
>>> that they can run by themselves if needed as well as run along with 
>>> any existing transactions. For logic that needs more than a single 
>>> call to a service, I then do something like this:
>>>
>>> txr.execute(new TransactionalExecution(){
>>>     public void execute() {
>>>                            Foo foo = fooService.getFoo(id);
>>>         if(foo != null) throw new FooException("No such foo exists!");
>>>                foo.setName(name);
>>>            }
>>> });
>>>
>>> TransactionalExecution is just an interface with a single method 
>>> execute() that exists just so we can create anonymous instances of it 
>>> to pass to txr, which would be an instance of 
>>> TransactionalExecutionRunner:
>>>
>>> public class JpaSpringTransactionalExecutionRunner implements 
>>> TransactionalExecutionRunner {
>>>        @Transactional(propagation=Propagation.REQUIRED)
>>>     public void execute(TransactionalExecution t) {
>>>         t.execute();
>>>     }
>>>        @Transactional(propagation=Propagation.REQUIRES_NEW)
>>>     public void executeRequiresNew(TransactionalExecution t) {
>>>         t.execute();
>>>     }
>>>        @Transactional(propagation=Propagation.MANDATORY)
>>>     public void executeMandatory(TransactionalExecution t) {
>>>         t.execute();
>>>     }
>>>    }
>>>
>>> (I'm sure you can figure out what the TransactionalExecutionRunner 
>>> interface says). You'd then declare the transactionalExecutionRunner 
>>> bean in your Spring context and have it injected into every action 
>>> created by the Spring object factory through autowiring for example, 
>>> and you're good to go. The cool thing about this is that your 
>>> controller code stays very clear and to the point with minimal 
>>> persistence bloat, and that any call to a service method from within 
>>> a TransactionalExecution will automatically run within the ongoing 
>>> transaction.
>>>
>>> As for your configuration, other than your applicationContext.xml 
>>> file you shouldn't have to do anything other than include the spring 
>>> plugin jar in your classpath. The jar comes with a struts-default.xml 
>>> file that sets Spring as the default object factory. Of course, it 
>>> can never hurt to explicitly set the objectFactory; I'm using 
>>> struts.objectFactory=org.apache.struts2.spring.StrutsSpringObjectFactory, 
>>> but struts.objectFactory=spring should work equally well.
>>>
>>> -- Jeroen
>>>
>>>    
>>>> Hi Jeroen,
>>>>
>>>> The problem is that I am not a big fan of services layer. Sometimes it
>>>> looks
>>>> very anemic to me. But I totally agree with you when you say the action
>>>> should not know about persistence problems, and that's why I want to do
>>>> it
>>>> via AOP.
>>>>
>>>> I had the same thought about the problem: the Spring proxy does not 
>>>> work
>>>> properly with all the magic Struts2 and Reflection do!
>>>>
>>>> I tried to open a bug in the Struts2 JIRA, but they closed it and said
>>>> that
>>>> it works. I think it should be some kind of spring or struts
>>>> configuration I
>>>> am not doing right.
>>>>
>>>> Thanks in advance,
>>>> Mauricio
>>>>
>>>> On Thu, Apr 30, 2009 at 11:22 PM, Jeroen De Ridder
>>>> <voetsjoeba@gmail.com>wrote:
>>>>
>>>>        
>>>>> You really shouldn't be making your Struts 2 actions @Transactional.
>>>>> Doing
>>>>> that causes Spring to create a proxy so it can put some extra
>>>>> transaction-handling logic between the method call and the actual
>>>>> method.
>>>>> The thing is, Struts 2 and OGNL rely heavily on reflection on the 
>>>>> action
>>>>> classes which simply does not work at all with the proxies created by
>>>>> Spring.
>>>>>
>>>>> Regardless, making your actions @Transactional means mixing 
>>>>> persistence
>>>>> concerns with controller logic in the same class. You should consider
>>>>> keeping the two separated. For example, the service approach is a good
>>>>> start:
>>>>> http://struts.apache.org/2.0.14/docs/struts-2-spring-2-jpa-ajax.html.
>>>>>
>>>>>
>>>>>  Yes, I am. Everything works fine when I don't try to use Spring
>>>>>            
>>>>>> transactional AOP!
>>>>>>
>>>>>> Mauricio
>>>>>>
>>>>>> On Thu, Apr 30, 2009 at 9:43 PM, Dave Newton <newton.dave@yahoo.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                
>>>>>>> Mauricio Aniche wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                    
>>>>>>>> I am using Struts2+Spring+JPA/Hibernate. When I use the
>>>>>>>> @Transactional
>>>>>>>> to
>>>>>>>> mark an execute() method in a Struts2 Action, the action
stops
>>>>>>>> working
>>>>>>>> properly (i.e. the attributes in the action are not automatically
>>>>>>>> setted).
>>>>>>>> It does not work with Spring AOP transactions as well.
>>>>>>>>
>>>>>>>> In my struts.config I setted the following constant:
>>>>>>>> ----
>>>>>>>> <constant name="struts.objectFactory" value="spring" />
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                         
>>>>>>> You're using the Spring plugin, correct?
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------

>>>>>>>
>>>>>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>>>>>> For additional commands, e-mail: user-help@struts.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                     
>>>>>>                 
>>>>>             
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: user-help@struts.apache.org
>>>
>>>
>>>
>>>     
>>
>>   
> 
> 

-- 
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
http://twitter.com/rgielen

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message