river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: code comment in TxnManagerImpl
Date Mon, 01 Apr 2013 07:36:57 GMT
On 1 April 2013 08:11, Peter Firmstone <jini@zeus.net.au> 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....

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message