river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Bug fixing
Date Tue, 26 Oct 2010 15:06:20 GMT
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

Mime
View raw message