checking custom prop data integrity

[George C Brackett]

Ah, I see.  I guess one option would be to offer as a service to  
maintain the data on a MySQL database on your own server, but you may  
not wish to get into such a long-term relationship.  I have often  
thought about the balance between offering  product and offering a  
service, and it's not obvious to me which might be better in general  
-- only in particular.

George

On Jul 21, 2009, at 1:50 PM, Phil Davis wrote:

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

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution