[Yanel-dev] Fwd: Cluster documentation
baszero at gmail.com
baszero at gmail.com
Thu Feb 3 07:41:53 CET 2011
Hoi Michi,
are your stress tests involving write access?
Cheers
Balz
_____________________
CTO
www.zwischengas.com
Sent from my iPhone
My latest Fotos:
http://tinyurl.com/lm2010pics
On 02.02.2011, at 23:20, Michael Wechner <michael.wechner at wyona.com> wrote:
> On 2/2/11 10:56 PM, Cedric Staub wrote:
>> On Wed, Feb 02, 2011 at 08:50:09PM +0100, Balz Schreier wrote:
>>> you got it :-) that's what I tried to explain: read, modify and update must
>>> be a single atomic operation.
>> Ok, so now I understand what you're trying to achieve. What I thought
>> of primarily was making sure that files don't get corrupted,
>
> I think our primary concern is that data does not get corrupted and
> also that if you have write and read at the same time, that the read
> doesn't get incomplete data.
>
> Using checkout/checkin solves the main part of the corruption problem, but
> the corruption can happen while setting the lock. The chances for
> this depend on how much the application is used for writing and
> how modular the data model is and in order to guarantee this in
> any case one could introduce a "singleton service" for locking (also see below re Amazon S3)
>
> The concurrent "write/read incomplete data" problem could be mainly solved
> by buffering the data, but this would still allow chances when "moving the buffer".
>
> Having said the above I think it's a question of time/effort versus chances if the problems
> from above actually happen. I would argue in many cases the chances are very small
> (this why we are currently running stress tests to have some real data on this instead of
> a guts feeling).
>
> If we want to really solve this problem properly independent of the repository implementation below,
> then I think we need to introduce something like a "synchronized singleton service" which can be used
> by the various cluster apps to get locks.
>
> Cheers
>
> Michael
>> not about
>> implementing transactions.
>>
>> Cedric
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
More information about the Yanel-development
mailing list