On 1 April 2013 08:11, Peter Firmstone <[email protected]> wrote: > Food for thought: After our pending release, it might be an idea to make > a combined effort to identify and address as many concurrency issues as > possible, we need to modernize our implementation code so we stay relevant. > > An important task will be updating all our service implementations so they > DON'T start threads during construction. > > The ActiveObject pattern often does start threads at construction. I'd like to understand why that is such a problem for you? It surely isn't a big deal for me but....
> Every time I fix one concurrency problem, performance usually improves and > another heisenbug appears. > > /* Expiration checks are only meaningful for active transactions. */ > /* NOTE: > * 1) Cancellation sets expiration to 0 without changing state > * from Active right away. Clients are supposed to treat > * UnknownTransactionException just like Aborted, so it's OK to send > * in this case. > * 2) Might be a small window where client is committing the transaction > * close to the expiration time. If the committed transition takes > * place between getState() and ensureCurrent then the client could get > * a false result. > */ > //TODO - need better locking here. getState and expiration need to be > checked atomically > This sort of thing is a big deal for me but has nothing much to do with starting threads in constructors....
