Greg Trasuk wrote:
The transaction spec says (under "Joining a Transaction") that "The join
method throws CannotJoinException if the transaction is known to the
manager but is no longer active."
So it would appear that this behaviour is a bug, if the transaction's
lease has actually expired.
I had a quick look through TxnManagerImpl and I don't see any
"auto-renew-on-join" behaviour, so that seems kind of odd. In fact, in
the join(...) method, it finds a TxnManagerTransaction instance, then
calls join(..) on it, which appears to check whether the transaction is
expired, and should throw CannotJoinException if it is expired.
There is an alternative I need to check. I want see if the JavaSpace is
caching the transaction information. Maybe it isn't even checking with
the TransactionManager if it thinks it has already joined the
transaction, regardless of the length of the transaction's lease.
Of course, logging and otherwise investigating the TransactionManager
will detect that as well, in the form of a missing join call for the
second write.
I'm not currently setup to run the tests, but if I were, I'd set the log
level on TxnManagerImpl to FINER and see if somebody is renewing the
lease on that transaction, then try to track down who it is.
No need for you to run tests. I'm set up to do that. Your comments and
suggestions are a valuable contribution to my bug hunt.
Thanks,
Patricia
