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