[Yanel-dev] Atomic operations in Yarep

[Balz Schreier]

I would not even try to implement something like the Java Transactions API.
Distributed transactions are one of the most complex topics in software
engineering, maybe it is the most complex at all...

I would rather think of offering "controlled" methods in addition to the
current API where the client doing the modification can choose between the
current API and the new ones.
The new ones could checkout the node, do the modification and checkin again
(as yarep offers today).

I understand that this is not designed and implemented over night, but it
would be a great addition to Yanel / Yarep.

When thinking of clustered environments, the solutions can look different:
- one single service that others "instances" can call remotely for doing the
changes?
- locking mechanism as described above? --> With the locking approach you
quickly run into the problem of needing a distributed filesystem (as of the
latest Lucene book, NFS, Samba/CIFS1.0 and Samba/CIFS2.0 have all severe
issues and are not good candidates to be used in write mode)
- other approaches?

Cheers
Balz

On Tue, Jan 25, 2011 at 10:32 AM, Michael Wechner <michael.wechner at wyona.com
> wrote:

> On 1/24/11 10:15 AM, Cedric Staub wrote:
>
>> Hello
>>
>>
>> On Fri, Jan 14, 2011 at 06:36:53PM +0100, Balz Schreier wrote:
>>
>>> do you agree that there is a potential of data inconsistency when
>>> modifying
>>> a Yarep Group from within your application?
>>>
>> Yes.
>>
>>
>>  Scenario:
>>> - The application itself can add and remove groups to a certain user,
>>> depending on what that user is doing in your application.
>>> - At the same time, a Yanel Administrator modifies memberships via the
>>> out
>>> of the box Group Mgmt page via toolbar.
>>>
>>> Now, the application can remove a membership like this:
>>>
>>>                    group.removeMember(user); // this also removes the
>>> group
>>> entry in the user XML and the user object gets saved!
>>>
>>>                 group.save();
>>>
>>> As you can see, there is no possibility that these two steps are done in
>>> 1
>>> step (in Java terms: synchronized).
>>> It also does not help if you write a Facade which does these two steps in
>>> a
>>> synchronized way because those modifications from the yanel admin page
>>> are
>>> still bypassing that facade.
>>>
>> I can see how that could go wrong.
>>
>>
>>  So my suggestion would be to extend Yarep by introducing this mechanism
>>> built-in, so that there is no way that files can get corrupt.
>>>
>>> If you agree, we should work once on a patch for Yarep where such
>>> operations
>>> are handled atomic.
>>>
>> Sure, but then what about other scenarios? I think what we really need
>> here is a facility which allows for transactions like a relational
>> database has them. But implementing that will be rather difficult I
>> imagine. How would you go about doing this?
>>
>
> maybe using
>
> http://en.wikipedia.org/wiki/Java_Transaction_API
>
> Just my two cents
>
> Michael
>
>> Cheers
>> Cedric
>>
>
> --
> Yanel-development mailing list Yanel-development at wyona.com
> http://lists.wyona.org/cgi-bin/mailman/listinfo/yanel-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wyona.org/pipermail/yanel-development/attachments/20110125/f6f7f18c/attachment.html>