I understabnd how to set the transaction timeout and know that after the timeout the transaction is put in a rollbackonly state.

My unit tests seem to indicate that an attempted commit() fails after a timeout (good!) but also causes the transaction to actually rollback because the usertransaction status changes to "No Transaction". This seems fine.

The question I have is what happens if the connection to the client is lost (in the case where we have a client [user]transaction)? For example, if the RMI connection went over the internet. Specifically, where a commit()/rollback() could not be issued beause the connection is lost.

When will the transaction actually be rolled back (rather than marked for rollback)? I am worried about any locks remaining on entity beans (or database records).

Some AppServers have a seperate [RMI] session timeout which triggers the transaction rollback, others force a rollback (i.e. rather than just setrollbackonly()) on transaction timeout (safer IMO). This is not available in JBOSS (I am using version 3.2.2RC3 - are there any changes in version 4?) - so what should users do?

Is the only answer not to use client transactions - but rather start all transations on a [session] bean?

When searching the web and forums I did find some refernces - but I can't find them now.

After your reply I did some further tests. And basically yes - I do get a Rollback about 10-14 minutes later, and an error is logged "[UserTransactionSessionImpl] Lost connection to UserTransaction clients: Rolling back 1 active transaction(s)". This is very good and answers my concerns.

I assume that the java.rmi.dgc.leaseValue is important - it is set by default to 10 minutes - and the rest of the delay depends on when the gc kicks in.

I have no idea how I would change the RMI leaseValue in Jboss, but am not very worried about that - 10 minutes seem fine to me.