Event handling vs. concurrent/rolled back transactions

From: Holger Hoffstätte (holge..izards.de)
Date: Mon Jan 20 2003 - 08:48:22 EST

  • Next message: Andrus: "Re: Event handling vs. concurrent/rolled back transactions"

    It just dawned on me that the current event handler has some problems with
    concurency and aborted transactions, since it's implemented as stateful
    singleton.

    - DC#1 starts commitChanges() and posts #willCommit
    - DCEventHandler collects objects #1 to be notified & notifies them
    - DC#2 in another thread is scheduled to commitChanges() & posts
    #willCommit
    - DCEventHandler again collects objects #2 & notifies them
    - DC#1 is scheduled again, finishes and posts #didCommit
    - DCEventHandler happily messages the wrong set of objects: #2 instead of
    #1
    - DC#2 finishes and posts #didCommit
    - DCEventHandler starts complaining about missing objects #2

    Transaction rollback looks similar (DC#1 or #2 rolling back between
    events), but with the same results. I think two things might help here:

    1) wrapping commitChanges() in a single try/catch/finally so that method
    entry/exit can be controlled better. Right now it's kind of messy..

    2) event handler will keep track of each DC's state individually

    3) a new dataContextRolledBack event so that the handler can clean up
    properly

    Does this sound reasonable? Anything I've missed? I'm not particularly
    fond of the singleton, but the other solution that I thought of
    (internally spawning 'child instances' for keeping track of
    per-transaction DC state) didn't really bring any new revelations either.
    Might look cool, though. ;)

    Holger



    This archive was generated by hypermail 2.0.0 : Mon Jan 20 2003 - 08:49:15 EST