On Thu, Sep 24, 2009 at 6:01 AM, Frans Thamura <fr...@meruvian.org> wrote:
[snip]
>
> there is declarative transaction inside spring that may be can benefit
> S2 apps, can share this experience?
>
Frans, I use Spring's declarative transaction management, but there
are some caveats. The biggest being that it depends on AOP. This is
subtle, but I have been bitten by a few of the side-effects. First of
all, behind the scenes, Spring tries to use Dynamic JDK proxies which
imposes the requirement that the "intercepted" methods must be
implementations from an interface. This means that if you try to use
@Transactional on an action method like the following -
public class SomeAction extends ActionSupport {
...
@Transactional
public String someInterestingMethod() {
doSomethingInteresting(BusinessClass bizInstance);
return SUCCESS;
}
}
This does not work, since you can see from the class declaration,
SomeAction is not implementing an interface that exposes 'public
String someInterestingMethod();' This is easily mitigated by
configuring Spring to use CGLIB rather than JDK proxies. This imposes
a rule though that any classes using @Transactional must have a
default, no-arg constructor.
The next issue that bit me was that 'self-invocation' does not work
(which makes sense and I should have known it wouldn't work).
Self-invocation is a situation like this -
public class SomeServiceImpl implements SomeService {
...
@Transactional
public BusinessClass save(BusinessClass bizClass) {
...
}
public BusinessClass create(String id, String value) {
BusinessClass newInstance = new BusinessClass();
newInstance.setId(id);
newInstance.setValue(value);
return save(newInstance);
}
}
Notice that 'create' doesn't have @Transactional? It shouldn't need
it, right, 'save' has it... Well, this doesn't work. The call to
'save' isn't intercepted (IIRC, it doesn't matter if the proxies are
JDK or CGLIB).
That being said, declarative transaction management is great! I still
prefer it, and just work around these issues. I have found that if I
separate things appropriately (service = interfaces, implementations =
spring beans) then I don't have to worry too much. I don't mess with
transactions in Struts actions and if I feel like I need a transaction
in an action, I just refactor the service.
-Wes
PS. As to Spring 3, as soon as it's released, we will work toward
getting it working.
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
