Today I want to talk about a detail in the JSF Framework, which is on the first view not obviously. In different to Spring, business logic placed in a JSF front-end controller (JSF Backing Beans) did not initializes a separate transaction context. Normally business logic which need to be transaction save should be spread out into EJBs. EJBs are the recommended place for business logic. So in JSF/EJB business logic should be put into stateless session EJBs and controlled the page flow of a web application through the so called front end controllers – JSF Backing beans. As I mentioned before spring starts a transaction context also in front-end controllers, but jsf does not.
So what is the problem here? When you look at the following JSF example, you maybe will not recognize the problem at first:
//jsf bean...
@EJB ejb1;
...
public String process(businessobject) {
ejb1.op1(businessobject);
ejb1.op2(businessobject);
....
}
The JSF front-end controller method ‘process(businessobject)’ injects an EJB and calls two ejb methods. This will propaply work without any side effects. But it can produce errors in some cases. The problem in this pattern is that the front-end controller performed two apparently dependent business actions completely separately. If these two methods need to be transaction save but are operating on the same database entities this can result in serious problems. In a high concurrent system indeed this pattern can cause a corrupted DB state even if you thought JPA will solve all the transaction stuff for you.
The reason for the unexpected behavior is the missing wrapping transaction. Each ejb method starts it own transaction with all the transaction control provided by the ejb container. But the hole business method is not transaction save.
To solve this you have two possible solutions:
1) add a UserTranaction context to the front-end controller:
//jsf bean...
@Resource UserTransaction tx;
@EJB ejb1;
...
public String process(businessobject) {
try {
tx.begin();
ejb1.op1(businessobject);
ejb1.op2(businessobject);
finaly {
tx.commit();
}....
}
In this example now the jsf controller starts itself the UserTransaction. As a result both EJB methods (with default transaction mode ‘mandatory’) run in the same transaction context. Even operations on the database in a high concurrent system will be transaction save.
2) Merge the EJB Methods into one transaction save business method
The second solution merges both ejb methods into a single EJB method call:
// JSF bean calls new ejb method...
public String process(Entity entity) {
ejb1.op1op2(entity);
// ...
}
with the following ejb implementation:
// EJB
public void op1op2(Entity entity) {
op1(entity);
op2(entity);
}
Now the new ejb method is transaction save an there is no need to fiddle with UserTransaction in the jsf fornt-end controller.
The second solution is recommended because there is no more risk that the transaction context is split by the front-end. And you can reuse the new ejb method easily with now need to think about the transaction context scenarios.
Maybe this will help you solving some problems with jsf transaction context in the future.
