ENvironment:
- JBoss AS 4.2.2GA
- RedHat Linux
- Oracle 10g
- Java EE 1.4, EJB 2.0
- iBatis 2.3.4 as persistence framework
Machines A, B hold clustered JBoss AS
Machine C holds a NON-clustered JBoss AS
Control of persistence operations is held by A,B only.
All of Ejbs involved are Session Beans.
1) EjbC1 (Enterprise Java Bean instance 1 on C) starts a transaction (i.e. starts a
business method)
2) EjbC1 makes a remote call to EjbA/B1 (instance 1 of Ejb on either A,B, depends on
redirection)
3) EjbA/B1 executes a SELECT FOR UPDATE on db table T1, to lock rows and prevent unwanted
concurrent updates
4) Control returns to EjbC1 that uses selected rows for some business logic
5) EjbC1 makes a remote call to EjbA/B2 that saves results (modified rows) to db table T1
6) EjbC1 ends the transaction(i.e. returns from method)
The problem is: once the control returns from EjbA/B to EjbC (step 4) the DB locks are
lost. To ensure consistent updates of the data set, we expect that another instance of
EjbC finds the rows locked, and can't therefore perform the select, until the EjbC
instance who started the transaction has finished its work.
In other words:
1) EjbC1 (Enterprise Java Bean instance 1 on C) starts a transaction (i.e. starts a
business method)
2) EjbC1 makes a remote call to EjbA/B1 (instance 1 of Ejb on either A,B, depends on
redirection)
3) EjbA/B1 executes a SELECT FOR UPDATE on db table T1, to lock rows and prevent unwanted
concurrent updates
4) Control returns to EjbC1 that uses selected rows for some business logic
5) EjbC2 (different instance of Ejb on C) starts a new transaction
6) EjbC1 makes a remote call to EjbA/B2
7) EjbA/B2 tries a SELECT FOR UPDATE, should find a lock, does NOT find a lock and reads
rows
8) Control returns to EjbC2 that uses selected rows for some business logic
9) EjbC1 makes a remote call to EjbA/B3 that saves results (modified rows) to db table T1
10) EjbC1 ends the transaction(i.e. returns from method)
11) EjbC2 makes a remote call to EjbA/B4 that saves results (modified rows) to db table
T1, thus LOSING modifications saved at step (9)
12) EjbC2 ends the transaction(i.e. returns from method)
I hope I have described everything clearly enough.
The question is: why are db locks lost ? I know they can be lost if a commit/rollback is
performed. Then I must think there is a spurious commit in the middle of the transaction?
Thanks for any help
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204498#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...