>>>>> "da" == Derek Atkins <[EMAIL PROTECTED]> writes:
da> Locking is a challenging thing. You can't just depend on the
da> filestore to lock data; what happens if you have something
da> like looks like this:
[...]
da> What do you do? Presumably the DB can serialize (lock)
da> requests, so you don't get intersperced data. But you need
da> more than that. In this particular case, User1 got to the DB
da> first, so presumably user2 would receive a callback about the
da> change to obj1. However, User2 already tried to commit the
da> data.. What's the DB to do?
You need a database that supports "select for update". At some point
the GUI decides the user is about to modify data and so issues a
"select for update" to obtain a lock on the data. This limits what
databases you can support. The second user does the same and blocks
until the first one completes, at which point the second user gets the
newer data. Note that this may have the disconcerting effect of the
data changing when the user starts to edit it....
roland
--
PGP Key ID: 66 BC 3B CD
Roland B. Roberts, PhD RL Enterprises
[EMAIL PROTECTED] 76-15 113th Street, Apt 3B
[EMAIL PROTECTED] Forest Hills, NY 11375
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
