> "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)
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> I don't see how the locking problem is a CM concern. I mean that you will
> have to solve the locking problem at the level of storing the new data before
> you need to worry about multilpe GUI's trying to read the file to see what
> needs to be cha
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> Are you thinking of `locking ' at the transaction level or account
> level. The example that comes to mind is: One person is reconciling
> last months records and someone else is entering this months
> transactions. As these modifications don't cl
Derek Atkins wrote:
> Phillip J Shelton <[EMAIL PROTECTED]> writes:
>
>
> > Would something like having user A have the only permissions to
> > change things if they opened the account first be a usefull first
> > pass. Or is that too simple?
>
> How does the UI know whether the user intends to m
Phillip J Shelton <[EMAIL PROTECTED]> writes:
> Hmm, this is the CVS merge problem isn't it?
Basically, yes.
> Would something like having user A have the only permissions to
> change things if they opened the account first be a usefull first
> pass. Or is that too simple?
How does the UI know
Derek Atkins wrote:
> Presumably the DB can serialize (lock) requests,
> so you don't get intersperced data. But you need more than that.
> In this particular case, User1 got to the DB first, so presumably
> user2 would receive a callback about the change to obj1. However,
> User2 already tried
