On Tue, Jun 20, 2006 at 09:18:33PM +1000, Ian Haywood wrote:
> However you seem to be solving this 3 ways at once:
> 1- recieving NOTIFY events to reload widgets
> 2- using SELECT .. FOR UPDATE
> 3- checking xmin on UPDATE and DELETE
- 1) is unrelated to 2) and 3) and unrelated to concurrency/locking issues
- 2) select for update
- whenever I want to make sure I can safely write to a row I must do
"select for update" on that row
- this will prevent other transactions from *writing* to that row
until I release that lock by "commit"
- 3) checking XMIN
- after my "select for update" no one else can *write* that row
until I commit
- therefore, the timespan between "select for update" and commit
should be minimized
- therefore I only "select for update" right before actually writing
- however, the user has seen data on screen from much earlier, namely
when the initial, simple "select" was done
- other people might have overwritten that data in the database
in the meantime (yes, I have seen it happen)
- they, too, properly locked the data but the lock is released again
because they already finished their write
- now I want to write *my changes* to the backend
- if no one else has locked the row I can do that *regardless*
of *what* is actually in the database *right now*
- that way I could overwrite other people's interim changes
without ever knowing they existed
- this is unacceptable
- therefore I check XMIN before I write to the backend
- it must be the same XMIN as when I initially read the data
- or else someone has overwritten the data in the meantime
- XMIN is a PostgreSQL internal "timestamp" telling me who
last *modified* a given row
- if XMIN changed between me reading/displaying the data and me
wanting to save changes I *know* someone else modified it
- at which point I need to inform the user about that fact
> Why all 3? (I'm sure there's a good reason, I just can't figure it out)
I cannot for the life of it explain it any more clearly than that.
> > That is a misconception. However, it may very well be
> > sufficient to put a wrapper around them which handles them
> > in an invisible, default way such that you don't have to
> > worry about them. As if they were not there. But they are
> > still handled. Just that you don't have any control over
> > them.
> How to encapsulate cleanly is the big issue.
I fully agree. I have up to now only been able to come up
with the encapsulation you currently see in the middleware.
Not pretty but - AFAICT - safe (yes, it has already
prevented inconsistent data from entering the database).
>>> [And the refusal to delete my old unused code is just infuriating.
>>> we're using CVS for god's sake: we can always get it back!]
>> Look at client/gmDemographicsWidgets.py again :-)
> Ok, thanks.
> The code is now very garrulous, but at least sane.
I fully agree it is garrulous ! But that's stock wxPython
code (hence I don't really agree it is sane ;-) Dabo might
make it more palatable.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
_______________________________________________
Gnumed-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnumed-devel
