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