« Return to Thread: ConcurrentModificationException, Cannot begin a new event ... - reproducible

Re: ConcurrentModificationException, Cannot begin a new event ... - reproducible

by Emil Crumhorn :: Rate this Message:

I completely agree. It seems to me it should be possible to make a "mistake" without getting the entire list system out of order. Normal java lists just continue to work even if you mess up the index (after throwing an exception of course).

Unless there's a big reason why the commit can't finish despite the error, it seems to me this would be an easy fix and at least you'd get the lists back on track. Now I have to explicitly check indexes before a set just so that I never get an IndexOutOfBounds exception, as if I get one, then I can't use the lists anymore.

Emil

Endre Stølsvik-8 wrote:

I've been wondering about this: shouldn't the beginEvent-commitEvent
always be in a try-finally block? This to contain any errors as best
one can? It seems to me like any error anywhere in the pipeline now
will lead to an irreparably inconsistent state, while if one had
try-finally, with the updates.["change"] always after the actual data
change invocation method, one would get something that at least in
several situations resembles a transaction with both commit and
rollback semantics.

This would be so that even though there are some logic errors to could
come up in certain situations, the application using GL would still
have a chance of being consistent after an error - of being able to
recover out of errors.

Endre.

On Sun, Apr 26, 2009 at 11:06, Holger Brands <hbrands@web.de> wrote:
> > Is this the expected behavior?
>
> Yes, with the current implementation, that's expected.
> If you dive into the implementation you'll see this:
>
> public E set(int index, E element) {
> // create the change event
> updates.beginEvent();
> // do the actual set
> E previous = data.set(index, element);
> // fire the event
> updates.elementUpdated(index, previous);
> updates.commitEvent();
> return previous;
> }
>
> Event delivery is guarded by calls to
> ListEventAssembler.beginEvent() - start recording changes
> and
> ListEventAssembler.commitEvent() - propagate recorded changes
>
> When an uncaught exception is thrown inbetween, commitEvent()
> is never called and no change events are fired.
> With the next call to beginEvent() the ListEventAssembler detects,
> that an event delivery is in progress leading to the ConcurrentModificationExceptions
> you observed.
>
> Holger
> __________________________________________________________________________
> Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele
> ausländische Netze zum gleichen Preis!
> https://produkte.web.de/webde_sms/sms
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glazedlists.dev.java.net
> For additional commands, e-mail: users-help@glazedlists.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glazedlists.dev.java.net
For additional commands, e-mail: users-help@glazedlists.dev.java.net

« Return to Thread: ConcurrentModificationException, Cannot begin a new event ... - reproducible