checking custom prop data integrity

[Phil Davis]

George C Brackett wrote:
> Is the purpose of the online stack just to hold the value of the 
> custom property?  If so, why not use a database such as MySQL or 
> PostgreSQL?  These are carefully engineered to prevent collisions by 
> multiple users.
>
> George

You're absolutely right, George - MySQL etc offer superior data 
management capabilities. But often the introduction of a conventional 
DBMS brings with it the need for more technical support. Most small 
businesses (at least the ones this product serves) don't have a tech 
support person on the payroll and want to keep it that way. By using 
this simple dumb-data-on-server / smart-app-on-every-client approach, 
even the owner of the company can usually restore the server data if 
something goes wrong! Imagine that. ;-)

Phil

>
> On Jul 20, 2009, at 7:59 PM, Phil Davis wrote:
>
> I'm looking for the best way to detect data corruption ASAP after it 
> happens in a custom property of a stack. The stack resides on a file 
> server and is read & written by many clients. File locking during 
> reads and writes is already in place and seems to be doing its job, 
> but occasionally we still have data corruption that creeps in.
>
> Specifically, I want to make a way for the "Client B" app to know that 
> the value it gets from the "uData" custom property of stack "myStack" 
> is exactly what the "Client A" app put there a moment before.
>
> Here's how I see this working:
>
>   * Client A
>         o (stack is in memory, file is locked on server)
>         o sets the uData of stack "myStack" to new value
>         o puts md5digest of updated uData into "dataDigest" file on 
> server
>         o saves "myStack" stack
>         o deletes stack from memory
>         o unlocks file on server
>   * Client B (a moment later)
>         o locks "myStack" file on server
>         o puts "dataDigest" file from server into tOldDigest
>         o goes to stack "myStack"
>         o puts md5digest of uData custom prop into tNewDigest
>         o if tNewDigest = tOldDigest, all is well; otherwise
>           corruption exists
>
> Does anyone see a problem with this approach? Is there a better way to 
> accomplish the goal? If each client could check the data after its own 
> write without having to read the stack into memory again to do so, 
> that would be great - I just didn't see a way for that to happen.
>
> Thanks everyone -

-- 
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net