checking custom prop data integrity

[Andre Garzia]

Phil,
        o try to lock the file
        o verify the lock
        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 try to read the uData of the stack
        o compare it with stored md5digest
        o if ok, unlock the stack, else, try again
        o unlocks file on server

I am paranoid with race conditions, like when you tell it to lock and in the
miliseconds before locking, someone else acquire the lock and you think the
lock is yours. Also, you need some way to detect astray locks, like when the
client exits with the file locked. Usually, I write the milisecs to my lock
file, and since most of my write operations are small, when I check for a
locked file, I check if more than 5 seconds have elapsed since the lock was
acquired, if so, it's a rogue lock file and should be unlocked by force.

Another more difficult approach is having a folder and each client writes to
it's own file only, so, they cannot overwrite each other, but when you're
reading, you read them all and merge it's content. Or if the data is
duplicated, you decide which one is current based on time or version or
something. This way you have no race condition or corrpution but you need
some clever merging/deciding routine.

my 2 brazilian reals cents which are worth nanopeanuts these days

On Mon, Jul 20, 2009 at 8:59 PM, Phil Davis <revdev at pdslabs.net> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.