Well, the concurrency approach was an erlang-ish "fail fast, fail safely"
which helped to speed up things but also sometimes led to inconsistency and
random errors. Maybe it's time to change.
Ciao,
R
Il giorno 26/feb/2012 02:06, "Simone Tripodi" <[email protected]> ha
scritto:
> +1 concurrency is still an open issue in DM
>
> best,
> -Simo
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Sun, Feb 26, 2012 at 1:33 AM, Michael André Pearce
> <[email protected]> wrote:
> > Also can i suggest locking on the key for put/updates/deletes? avoids
> someone getting a key whilst it is in transitive state of being updated by
> another, ive seen before a fancy way of doing this, avoiding a lock for
> every key, will have to try remember.
> >
> > On 26 Feb 2012, at 00:24, Simone Tripodi wrote:
> >
> >> Hi all guys,
> >>
> >> I had a chat with Benoit in another thread and I realized no one of
> >> our class is Thread safe - what do you think of actual behavior that
> >> every component accepts a setter for any member - that could cause
> >> strange behaviors at runtime?
> >>
> >> I would analyze wich components can be converted to immutable - IIUC
> >> Benoit agreed with me on having some PointerImpl members as immutable,
> >> i.e. CacheService#setMap( ConcurrentMap<K, Pointer<V>> map ) means
> >> dropping all the already stored data :)
> >>
> >> Thoughts?
> >> best,
> >> -Simo
> >>
> >> http://people.apache.org/~simonetripodi/
> >> http://simonetripodi.livejournal.com/
> >> http://twitter.com/simonetripodi
> >> http://www.99soft.org/
> >
>
