In many large apps, some processes require multiple actions to be performed. For example, user edits or creates many items on the screen, all items have to be saved one by one and cannot be done all at once. This is not mostly the case with JPA entities, but rather custom data and old way of doing things. This can be the case for example when inserts are done to different tables or databases and on top of that result from one insert is used for the next one. Unfortunately there is tons of interesting data models with which developers and users have to deal with. In order to relieve already overstressed users from waiting on submit for a set of newly created or edited items, one may decide to execute them in parallel and when all is finished, display the results to user. In the context of en EJB 3.1, this is what the spec says:
"There is no need for any restrictions against concurrent client access to stateless session beans because the container routes each request to a different instance of the stateless session bean class..."
What if, I have a list of date that I want to persist concurrently, each in a thread, wait until all is finished and proceed? Assuming I am not using @Asynchronous option, which is only available in 3.1. So I tried to use an executor service:
EJB which is supposed to be called from different threads:
1
2
3
4
5
6
| @Local
public interface TestConcurrentEJBAccess {
public void test();
}
|
1
2
3
4
5
6
7
8
9
10
| @Stateless
public class TestConcurrentEJBAccessBean implements TestConcurrentEJBAccess {
@Override
public void test() {
System.out.println("Inside the TestConcurrentEJBAccessBean: " + this);
}
}
|
Following is an actual caller implementation:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
|
@Stateless
public class ManageServiceBean implements ManageService {
@EJB
private TestConcurrentEJBAccess testConcurrentEJBAccess;
...
@Override
public int saveTable(List<Val> lookup, final String user) {
...
List<Callable<Integer>> callables = new ArrayList<Callable<Integer>>();
ExecutorService es = null;
try {
final InitialContext sctx = new InitialContext();
for (final LookupVal lookupValue : changed) {
Callable<Integer> c = new Callable<Integer>() {
@Override
public Integer call() throws Exception {
// execute test
testConcurrentEJBAccess.test();
}
};
callables.add(c);
}
es = Executors.newCachedThreadPool();
List<Future<Integer>> results = es.invokeAll(callables);
System.out.println(System.currentTimeMillis() - start);
for (Future<Integer> future : results) {
totalResult += future.get();
}
// Next is exception handling other not interesting stuff
...
}
}
|
Here is the console output:
1
2
3
4
5
6
7
8
9
10
| Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@19f72db
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@19f72db
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@19f72db
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@19f72db
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@19f72db
|
Same EJB instance is being invoked, just from separate threads! But that is not what i wanted. I wanted separate for each "client". Each invocation does however run in its own transaction, as seen from following modifications:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
| import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.transaction.TransactionSynchronizationRegistry;
import weblogic.transaction.internal.ServerTransactionImpl;
@Stateless
public class TestConcurrentEJBAccessBean implements TestConcurrentEJBAccess {
@Resource
private TransactionSynchronizationRegistry tsr;
@Override
public void test() {
System.out.println("Inside the TestConcurrentEJBAccessBean: " + this +
" transaction: " + ((ServerTransactionImpl)tsr.getTransactionKey()).getXid());
}
}
|
and output:
1
2
3
4
5
6
7
8
| Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@1e20bd1 transaction: BEA1-025A2FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@115b3a transaction: BEA1-02592FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@175d190 transaction: BEA1-025B2FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.TestConcurren
tEJBAccessBean_6ali4g_Impl@175d190 transaction: BEA1-025C2FE57008E8E9B79B
|
Transaction ID is different in all cases. So this is ok. Also from the output there is 3 separate instances and not one, like I thought at first. Lets however try to get a separate instance per callable. For that we modify our ManageServiceBean on how we invoke TestConcurrentEJBAccess:
1
2
3
4
5
6
| // execute test
//testConcurrentEJBAccess.test();
((TestConcurrentEJBAccess) sctx
.lookup("java:comp/env/ejb/TestConcurrentEJBAccess"))
.test();
|
Now the output:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03AC2FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03B22FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03B42FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03B62FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03B82FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03BB2FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03BF2FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03C02FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03C12FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03C22FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03C32FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03C42FE57008E8E9B79B
Inside the TestConcurrentEJBAccessBean: com.test.conc.aplf.ejb.spb.testconcurren
tservice_g1cl98_Impl@a6ed65 transaction: BEA1-03C52FE57008E8E9B79B
|
The instance is the same! In any case there is no control of which instance of a stateless EJB, the container will provide...
In any case it doesn't matter same instance or not. What matters is if concurrency inside an EJB is justifying enough or not. This needs to be measured and calculated, since there may be a single point of synchronization for running threads, waiting for a lock in which will not provide any benefit for parralelizing an algorithm.
