I have a CDI conversation scoped action class which I am also making a stateful EJB for holding state of objects throughout the conversation life cycle.
As the action class is an EJB, so by default all methods will be transactional, which I intentionally don't want to do. I just want a single method of the action class will be transactional where I will only perform database persistence tasks. So I annotate that single method with #TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). And the action class is annotated with #TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED).
When I call the transactional method from other handler methods of the same action class, there no transaction starts.
Here is the code sample.
#Stateful
#Named
#ConversationScoped
#TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class MyAction implements Serializable {
#PersistenceContext(type = PersistenceContextType.EXTENDED)
private EntityManager em;
........
........
........
public String handlerMethod1() {
// do some staffs.
persist();
return "view";
}
public String handlerMethod2() {
// do some staffs.
persist();
}
.......
.......
.......
#TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
private void persist() {
// save objects.
em.flush();
}
}
No transaction starts when invoked persist() method though I have annotated it with #TransactionAttribute(TransactionAttributeType.REQUIRES_NEW), but why?
Please help me getting rid of this.
You have two problems here:
a) persist() is not a business method. A Business method have to be (among other rules) public.
b) you are calling the persist() method with a simple object method invocation, therefore, the Container is not able to manage the code. Remember that #TransactionAttribute annotation needs to be interpreted by the Container, which doesn't occurs in this case.
One possible solution could be to create other EJB with the persist() method code and inject him in MyAction bean.
This way, every time you invoke the persist() method, the Container will intercept the call and it will create a new transaction.
Related
I have a few questions about #Transactional annotation. If I have an implementation similar as below:
#Transactional
public Interface ExampleRepo {
SampleClass createRecord();
}
public class RepoImpl implements ExampleRepo {
public SampleClass createRecord() {
return saveRecord();
}
private saveRecord() {
//Saving record to Database.
}
}
Will the transaction rollback as Spring will ignore if the #Transactional was called on a private method? But what if a public method annotated with #Transactional calls a private method that actually does the database operation.
Will this transaction be marked as rollback?
As per Spring Documentation
Spring recommends that you only annotate concrete classes (and methods
of concrete classes) with the #Transactional annotation, as opposed to
annotating interfaces. You certainly can place the #Transactional
annotation on an interface (or an interface method), but this works
only as you would expect it to if you are using interface-based
proxies. The fact that Java annotations are not inherited from
interfaces means that if you are using class-based proxies (
proxy-target-class="true") or the weaving-based aspect (
mode="aspectj"), then the transaction settings are not recognized by
the proxying and weaving infrastructure, and the object will not be
wrapped in a transactional proxy, which would be decidedly bad.
So, I would recommend to use #Transaction at method createRecord() level or RepoImpl class level.
All code within a transaction scope runs in that transaction. However, you can specify the behavior if a transactional method is run when a transaction context already exists.
When a method without #Transactional is called within a transaction block, the parent transaction will continue to exist for the new method. It will use the same connection from the parent method (method with #Transactional) and any exception caused in the called method (method without #Transactional) will cause the transaction to rollback as configured in the transaction definition.
Since this mechanism is based on proxies, only 'external' method calls coming in through the proxy will be intercepted. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with #Transactional.
In the following setup, does method B run in a (new) transaction?
An EJB, having two methods, method A and method B
public class MyEJB implements SessionBean
public void methodA() {
doImportantStuff();
methodB();
doMoreImportantStuff();
}
public void methodB() {
doDatabaseThing();
}
}
The EJB is container managed, with methodB in requires_new transaction, and method A in required transaction. thus:
<container-transaction id="MethodTransaction_1178709616940">
<method id="MethodElement_1178709616955">
<ejb-name>MyName</ejb-name>
<method-name>*</method-name>
<trans-attribute>Required</trans-attribute>
</method>
<method id="MethodElement_1178709616971">
<ejb-name>MyName</ejb-name>
<method-name>methodB</method-name>
</method>
<trans-attribute>RequiresNew</trans-attribute>
</container-transaction>
Now let another EJB call methodA with an EJB method call.
methodA now runs in an transaction. Will the subsequent call to methodB from methodA run in the same transaction, or does it run in a new transaction?
(mind, it's the actual code here. There is no explicit ejb-call to method B)
Your call to methodB() is an ordinary call of a method, not intercepted by the EJB container; at run-time the EJB container will inject a proxy and not an instance of your class, this is the way it intercepts calls and setup the environment before calling your method. If you use this you're calling a method directly and not through the proxy. Hence both methods will use the same transaction, regardless to what is defined in ejb-jar.xml for calls through EJB interfaces.
inject SessionContext, and ask it for your proxy instance:
#Stateless
public class UserFacade implements UserFacadeLocal {
#Resource
private SessionContext context;
#Override
#TransactionAttribute(TransactionAttributeType.REQUIRED)
private void create(User user) {
System.out.println("Users Count: "+count()); //invocation#1
System.out.println("Users Count Through Context: "+context.getBusinessObject(UserFacadeLocal.class).count()); //invocation#2
}
#Override
#TransactionAttribute(TransactionAttributeType.NEVER)
public int count() {
return ((Long) q.getSingleResult()).intValue();
}
}
in 'invocation#1' this is a Local call, not passing through proxy, it will return the count
in 'invocation#2' this is a call through the proxy, and hence you annotate it not to support transaction -which is now opened by create(user) method-, this invocation will throw a transaction exception:
javax.ejb.EJBException: EJB cannot be invoked in global transaction
They will use the same transaction.
If I remember well, the transaction is started by the container "before" the method is invoked and commited after it "finish".
Since "a" calls "b", "b" would use the same transaction.
:S
I guess the best thing you can do is test it to verify it! :)
If i have two methods inside an EJB bean, one with Transaction attribute of NOT_SUPPORTED that needs to call the other with REQUIRED, can i expect the transaction to kick in if i make the call through an injected bean:
#Stateless
#LocalBean
public class LeBean {
#EJB LeBean bean;
#TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void someMethod(){
...
bean.otherMethod();
}
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public void otherMethd(){
...
}
}
or can i make the call locally like so:
#Stateless
#LocalBean
public class LeBean {
#TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
public void someMethod(){
...
otherMethod();
}
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public void otherMethd(){
...
}
}
right now someMethod() takes a long time to process information before reaching otherMethod() and so the transaction times out, even though i have stated NOT_SUPPORTED as the transactionAttribute for the first method.
can i expect the transaction to kick in if i make the call through an
injected bean:
You HAVE to make the call through the injected bean if you want a transaction. The calls have to be made through the business interface, or else your transaction attribute will be ignored. In your case if you call otherMethod() from a method that has no transaction, or a suspended transaction (i.e. - NOT_SUPPORTED) then it is simply a POJO call.
Technically speaking otherMethod() will "ride on top of" the transaction of someMethod() if one did exist. For example you have NOT_SUPPORTED for someMethod(), but if it were REQUIRED or REQUIRES_NEW, then otherMethod() would share in that transaction. A rollback for someMethod() would also rollback operations from otherMethod().
right now someMethod() takes a long time to process information before
reaching otherMethod() and so the transaction times out
That is a different issue altogether. You may wish to increase your transaction timeout, and consider running this as a separate asynchronous process.
Let's I have Stateless bean with CMT. I have 3 methods in bean, 2 with TransactionAttributeType.REQUIRED. And both method are called from third method. How can I check when transaction is active? i want check
#Stateless
#TransactionManagement(TransactionManagementType.CONTAINER)
public class MyBean
{
public RetType methodA()
{
methodB();
//.... is CMT active there?
methodC();
}
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public RetType methodB(){}
#TransactionAttribute(TransactionAttributeType.REQUIRED)
public RetType methodC(){}
}
The TransactionAttributeType.REQUIRED attribute is the default for container managed transactions bean methods, so even if you didn't annotate it, methodA runs in a transaction that starts as soon as the method starts (unless you call the method from another active transaction, in that case the method simply join the current transaction).
The transaction ends when the method upon method exit (again unless called from another transaction). Any method called by methodA, unless annotated with TransactionAttributeType.REQUIRES_NEW, joins the current transaction.
in one dao I have 2 #Transactional methods.
if i do not provide any explicit properties,
then what will happen, if
I run one method in the body of another?
Both methods will run within THE SAME ONE TRANSACTION?
Proxies in Spring AOP
When using Transactional, you're dealing with proxies of classes, so in this scenario:
#Transactional
public void doSomeThing(){ // calling this method targets a proxy
doSomeThingElse(); // this method targets the actual class, not the PROXY,
// so the transactional annotation has no effect
}
#Transactional
public void doSomeThingElse(){
}
you are calling the proxy from outside, but the second method call is made from inside the proxied object and therefor has no transactional support. So naturally, they run in the same transaction, no matter what the values of the #Transactional annotation in the second method are
so if you need separate transactions, you have to call
yourservice.doSomething();
yourservice.doSomethingElse();
from outside.
The whole scenario is explained pretty well in the chapter Spring AOP > Understanding AOP proxies, including this "solution":
Accessing the Current AOP Proxy object from the inside
public class SimplePojo implements Pojo {
public void foo() {
// this works, but... gah!
((Pojo) AopContext.currentProxy()).bar();
}
public void bar() {
// some logic...
}
}
The default value of the propagation attribute of #Transactional is REQUIRED, which means:
Support a current transaction, create a new one if none exists.
So yes - both methods will run in the same transaction.
But one important advice: don't make your DAO transactional. The services should be transactional, not the DAO.
Spring doc
one note:
In proxy mode (which is the default),
only external method calls coming in
through the proxy are intercepted.
This means that self-invocation, in
effect, a method within the target
object calling another method of the
target object, will not lead to an
actual transaction at runtime even if
the invoked method is marked with
#Transactional.